SG #38

Noticias SG38

lasr21 — Mon, 03 Dec 2012 10:26:33 +0000

Noticias SG38 lasr21 Mon, 12/03/2012 - 04:26

Publicado en

SG #38

Noticias

SoftMty 2012

El pasado 15 y 16 de Octubre se llevó a cabo SoftMty 2012, el evento insignia del Consejo de Software de Nuevo León. SoftMty reunió a ejecutivos de TI con el propósito de conocer tendencias y estrategias para lidiar con las principales necesidades de las áreas modernas de TI. Entre los temas que se abordaron estuvieron: análisis del presupuesto de las áreas de TI corporativas, cómputo empresarial en los corporativos, y manejo de contratos de outsourcing. SoftMty se dió el lujo de reunir a conferencistas internacionales de las firmas de análisis e investigación más prestigiadas del mundo como Gartner, Forrester y Cutter Consortium. Adicionalmente participaron como panelistas los CIOs de organizaciones tales como Comercial Mexicana, Coppel, CostCo, Gas Natural, Alestra, entre otros.

Hackathon por la Transparencia

A pesar de que ya se han realizado eventos en nuestro país para impulsar “datos abiertos”, lo relevante del hackathon realizado el pasado 19 y 20 de octubre es que fue una iniciativa de la misma Secretaría de Función Pública (SFP), a la que se unieron otras organizaciones como INFOTEC, Software Guru, Mapdata, Social TIC y Revista Política Digital. La app ganadora fue un servicio para localizar centros de salud cercanos. El segundo lugar se lo llevó la versión móvil del sitio “Tu Gobierno en Mapas” y el tercer lugar se lo llevó una aplicación para evitar que pases por lugares con alto índice delictivo.

Wowzapp México

Con una participación de más 17,000 desarrolladores alrededor del mundo, Microsoft organizó el pasado 9 y 10 de noviembre el hackathon global WOWZAPP 2012 para crear aplicaciones de Windows 8. Software Guru colaboró para convocar y organizar la sede de Wowzapp en Ciudad de México, donde se reunió a más de 140 desarrolladores. Sin duda, Microsoft y SG sentaron precedente en nuestro país.

Gartner CIO & IT Executive Summit 2012

Del 9 al 11 de octubre pasado, Centro Banamex Ciudad de México recibió a más de 300 personas especialistas, profesionales y estrategas de las Tecnologías de la Información en América Latina que durante dos días y medio accionaron sus habilidades de business networking, además de recibir insights, tips de estrategia e innovación así como tendencias en voz de los mejores analistas de Gartner que enfocaron su experiencia en cuatro tracks especializados: el CIO y el ejecutivo de TI, innovación de la información, aplicaciones empresariales e infraestructura y operaciones. Crédito: 360° Contenidos on Demand / Susana Tamayo

Talento Software

Por primera vez se realizó el Congreso "Talento Software" en la ciudad de Tehuacán, Puebla organizado por la empresa Link colectivo el 15 y 16 de noviembre. Talento Software contó con conferencistas nacionales e internacionales que expusieron tendencias y prácticas para que los profesionistas de software aprovechen las oportunidades que brinda nuestra industria. Como parte del evento se realizó también una Feria de Reclutamiento de Talentos, la cual dió la oportunidad a estudiantes y profesionistas de participar como aspirantes con empresas reclutadoras nacionales e internacionales.

Contacto Tractoras + PyMEs

lasr21 — Mon, 03 Dec 2012 10:24:09 +0000

Contacto Tractoras + PyMEs lasr21 Mon, 12/03/2012 - 04:24

Publicado en

SG #38

Reportaje

Gracias al apoyo de la Secretaría de Economía, a través del programa Fondo PyME, el pasado mes de octubre Software Guru llevó a cabo la segunda edición del evento Contacto Empresas Tractoras+PyMEs.

El evento reunió a grandes empresas en busca de productos y servicios de TI (empresas Tractoras), con empresas pequeñas y medianas (PyMEs) especializadas en dichos servicios, interesadas en iniciar una relación comercial ya sea como proveedores o como aliados.

Gracias a la coordinación de esfuerzos el evento logró:

La participación de 32 empresas Tractoras
350 PyMEs participantes
Más de 900 encuentros de negocio
Más de 500 asistentes

Durante el evento se llevaron a cabo encuentros presenciales entre empresas Tractoras y PyMEs, así como encuentros virtuales con empresas Tractoras localizadas en diferentes puntos del país.

Entre la demanda de las empresas Tractoras encontramos: prueba de aplicaciones, desarrollo móvil, soporte técnico, capacitación, consultoría, aplicaciones propietarias, seguridad en TI, PaaS, IaaS, SaaS, cloud computing, y los que no pueden faltar desarrollo a la medida y outsourcing. También se buscaron aliados para integración de aplicaciones, fábrica de software, venta de hardware y software, implementación de BI e implementación de Big Data.

Entre los lenguajes y plataformas más comunes solicitados podemos mencionar: .Net, PHP, HTML, CSS, Javascript, C++, Ajax, Python, JAVA, SQL, ORACLE, VWARE, CITRIX, TAMDEN B24, Androide y iOS.

Agradecemos a las empresas Tractoras por su valiosa participación en este evento: AXA, Buzón E, Centro Escolar Cedros, Coca-Cola FEMSA, CompuSoluciones, COSTCO, Dell, EBP Software, ERP Software, Estafeta, Excelerate Systems, Farmacias del Ahorro, GOBTEC, Grupo IAMSA, Grupo La Europea, Hildebrando, HP, IBM, ITKMAS, Logiti, Microsoft, N&S Trantor, Palacio de Hierro, Praxis, Renault, RIM, SAFENET, SAP, Secretaría del Trabajo y Previsión Social, T-Systems, Turrent Cameron y Ultrasist.

Agradecemos a ProMéxico, México First, y a la Cámara Nacional de la Industria de Transformación (Canacintra), por su participación como expositores durante el evento. De igual manera agredecemos a: AISAC, AMITI, CITI Tabasco, ClusterTIM, Csoftmty, CLUSTEC, e InteQsoft, por su apoyo en la difusión del evento.

SG continuará apoyando el desarrollo y sinergia entre empresas de TI, facilitando foros de encuentro y organizando diferentes actividades. Espera noticias.

KUALI-BEH y ESSENCE

lasr21 — Mon, 03 Dec 2012 10:22:22 +0000

KUALI-BEH y ESSENCE lasr21 Mon, 12/03/2012 - 04:22

Publicado en

SG #38

Tejiendo nuestra red

En SG #36 les conté cómo llegamos a competir con Ivar Jacobson y sus aliados en una convocatoria del Object Management Group (OMG) que buscaba propuestas para “A Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM)”. En febrero de este año enviamos a nombre de la UNAM (Miguel Ehécatl Morales Trujillo, Magdalena Dávila Muñoz y yo) la propuesta bajo el nombre de KUALI-BEH Software Project Common Concepts, mientras que el grupo de Jacobson presentó la propuesta de ESSENCE.

En marzo de este año, presenté a mi “hija” menor KUALI-BEH (sus “hermanos” mayores se llaman MoProSoft, Competisoft e ISO/IEC 29110-5-1-2 Perfil básico) en una reunión técnica de OMG. A su vez Jacobson presentó a su “hijo” ESSENCE (los “hijos” mayores de Ivar son muchos, los más destacados se llaman Casos de Uso, UML y Proceso Unificado). Desde que KUALI-BEH fue presentado nos dimos cuenta que a Ivar le pareció ser una competencia seria. Inmediatamente después de la reunión empezó a persuadirnos de que lo mejor para nuestro grupo era unirse a su propuesta y, a lo mejor, algunas pequeñas ideas de nuestra propuesta se agregarían a la suya; en otras palabras, pretendió desaparecer a KUALI-BEH. Esto no nos pareció justo, estábamos seguros de que nuestra propuesta tenía valor.

El 13 de agosto fue la siguiente fecha para la entrega ante OMG de las versiones mejoradas de las propuestas. A pesar de las presiones, decidimos mantener KUALI-BEH por separado. La fuerza para tomar esa decisión surgió del resultado del Taller Colaborativo en Métodos de Ingeniería de Software en el cual comprobamos que las ideas de KUALI-BEH son relativamente fáciles de asimilar. Además, recibimos una retroalimentación con 93 sugerencias, las cuales se analizaron, y 64 de ellas fueron consideradas para incorporarlas en la nueva versión. Agradecemos a DGTIC-UNAM, Magnabyte y JPE Consultores por su valiosa participación en este experimento entre la academia y la industria.

Cuando entregamos la versión 1.1 de KUALI-BEH en agosto, la insistencia de Jacobson para que nos fusionáramos volvió y se incrementó. En las negociaciones entre ambas partes intervino el Dr. Carlos Mario Zapata Jaramillo, profesor de la Universidad Nacional de Colombia y actual presidente del capítulo latinoamericano del SEMAT. Carlos Mario analizó ambas propuestas y propuso ideas para la fusión que preservaban las aportaciones de KUALI-BEH. Sus ideas fueron tomadas en cuenta por ambas partes y se llegó al acuerdo unos días antes de la segunda presentación ante el comité técnico de OMG el 12 de septiembre en Florida. En esta ocasión, por nuestra parte sólo pudo asistir Miguel, le tocaron las últimas negociaciones para armar y hacer una presentación conjunta. Así inició el noviazgo formal entre KUALI-BEH y ESSENCE. El presidente de la OMG Richard Soley y el propio Ivar Jacobson expresaron su júbilo.

Ahora nos tocan los preparativos de la “boda” prevista para el 12 de noviembre. Tenemos que integrar las dos propuestas en un sólo documento. Como en todos los preparativos de las bodas hay que conciliar los egos y los “usos y costumbres” de ambas partes. Nosotros estamos dispuestos a hacer todo para lograrlo y tratamos de ser flexibles para que esta fusión sea exitosa.

Cuando escribo esta columna falta un mes para la “boda”. Si logramos integrarnos, el documento final llevará el apellido ESSENCE del “esposo”, como en matrimonios polacos. Posteriormente será revisado y calificado por un Comité Evaluador. Curiosamente, se nos invitó a proponer candidatos para este comité y me imagino que lo mismo hará el grupo de Ivar. La decisión final de volver esta propuesta conjunta un estándar de OMG se tomará a través de la votación de los miembros nivel Platform de la OMG. El resultado se hará público el 10 de diciembre. Hasta este momento sabremos si va a haber “luna de miel”.

Esta “boda”, como todas, cuesta. La UNAM tiene que renovar en OMG su membresía platform (5,500 USD) para poder seguir participando y votar. La asistencia a las reuniones técnicas de OMG tampoco sale gratis. Por lo tanto vuelvo a invitar a todos mis lectores a que visiten el sitio http://www.kuali-kaans.mx para conocer como pueden apoyar y patrocinar este proyecto y de paso descargar el documento de KUALI-BEH 1.1 y llegar al sitio de estándares ISO, que son gratuitos. Por cierto, de este sitio pueden también descargar ISO/IEC 29110-5-1-2 Basic profile y recién salido del horno ISO/IEC29110-5-1-1 Entry profile. Este último dirigido a grupos de desarrollo muy pequeños (1 a 6 personas) y startups. Pueden encontrar el documento de ESSENCE en el sitio de SEMAT.

Figura 1. Miguel e Ivar al sellarse el acuerdo.

Bio

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

Lean y Desarrollo Ágil

lasr21 — Mon, 03 Dec 2012 10:19:04 +0000

Lean y Desarrollo Ágil lasr21 Mon, 12/03/2012 - 04:19

Publicado en

SG #38

Mejora continua

Recientemente me preguntaban si las metodologías ágiles son la respuesta Lean al desarrollo de proyectos. La idea es interesante; yo estoy convencido de que podemos utilizar herramientas de calidad en muchas partes, tanto de la administración como ingeniería del desarrollo de software, así que exploremos más esta idea.

La metodología Lean fue desarrollada por Toyota en los noventas, como una práctica de producción que considera como desperdicio el uso de recursos en actividades que no generen valor para el cliente, definiendo valor como todo aquello que el cliente esté dispuesto a pagar. Lean conlleva una serie de herramientas diseñadas para eliminar este desperdicio, entre ellas el mapeo de valor, las cinco S, Kanban (o proceso de jalar en lugar de empujar) y Poka Yoka (desarrollo a prueba de errores).

El modelo ágil de desarrollo de software se formalizó en el 2001 con el Manifiesto Ágil, aunque tiene raíces desde mucho antes. Este modelo busca la agilidad a través de valorar la interacción entre las personas, la colaboración y la flexibilidad al cambio. El manifiesto define doce principios enfocados a: satisfacción del cliente a través de desarrollo rápido; flexibilidad al cambio; entrega continua de software; entrega es la base del avance; flujo continuo a través de un paso constante; cooperación continua entre participantes; comunicación frente a frente; confianza en los participantes; búsqueda de excelencia; simplicidad; auto-organización; adaptación a circunstancias de cambio.

A primera vista, el manifiesto promueve todos los principios de Lean: establece un modelo de Kanban, donde se tiene un paso continuo; una estructura en donde el cliente rige cada iteración, que puede ajustarse continuamente; estipula también una reducción de documentación y la cercanía de los participantes para poder asegurar una mejor comunicación.

Lean se creó como una herramienta de manufactura, por lo que requiere ser adaptada para ser utilizada en servicios. La principal adaptación que sufre es la modificación de los elementos que se consideran desperdicio. A continuación explico como Ágil ataca los problemas de desperdicio.

Desconocimiento de expectativas del cliente. Ágil ataca este problema al generar entregables continuos, y al tomar como medida de avance el software funcionando. Esto establece en forma indirecta que la participación del cliente siempre está relacionada con avanzar.

Energía y duplicidad de trabajo. Aunque Ágil fomenta el generar trabajo a través de pares, esto no va contra este principio porque la idea detrás de esto es que cada individuo busque defectos desde un punto de vista diferente, minimizando así el re-trabajo.

Errores de comunicación. Ágil fomenta la comunicación verbal como una forma eficiente de obtener claridad.

Inventario incorrecto. A diferencia de metodologías que miden el avance de un proyecto en base a actividades realizadas, en Ágil el avance se mide en términos de “software funcionando”.

Errores en el servicio. Lean fomenta un retroalimentación continua y la detección de errores lo antes posible a través de revisión y retroalimentación continua.

Potencial humano no utilizado. Lean fomenta la participación de todos en todas las etapas de desarrollo y la distribución de roles en forma grupal.

En base a esta rápida comparación, definitivamente Ágil se puede considerar como una forma Lean para desarrollar software y que por lo tanto acarrea sus beneficios.

Tips para la adopción

Un inconveniente de Ágil es que al ser tan flexible, las implementaciones pueden variar considerablemente, permitiendo mucho uso inapropiado del modelo. Por ejemplo, recordemos que Lean considera valor agregado todo aquello que está dispuesto a pagar el cliente, por lo que si el cliente paga por tener documentación de su sistema, eso es parte de los entregables.

Otra situación común es que los equipos decidan eliminar actividades como reuniones periódicas de retroalimentación o programación en pares, las cuales tienen una razón de ser; eliminarlas sin cuestionar cómo sustituimos las prácticas equivale a remover acciones de valor agregado del modelo.

Por otro lado, no debemos ser tan rígidos, ya que seguramente nos encontraremos con situaciones especiales donde ya sea por tamaño de proyecto o dispersión geográfica, es posible sea necesario aplicar prácticas de metodologías no tan ágiles.

En resumen, definitivamente las metodologías ágiles son una excelente solución al desarrollo de software pero como todo en esta vida tenemos que cuestionar la razón de las actividades que vamos a llevar a cabo, y más importante, cuestionar la razón de las actividades que decidimos dejar de implementar

Bio

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

Lo Que Viene

lasr21 — Mon, 03 Dec 2012 10:15:46 +0000

Lo Que Viene lasr21 Mon, 12/03/2012 - 04:15

Publicado en

SG #38

Herramientas y Tecnologías

Icenium

Olvídate del IDE, lo de hoy es el ICE

Icenium, denominado el primer Integrated Cloud Environment (ICE), es un ambiente de desarrollo móvil cross-plataform que combina el poder y flexibilidad de la nube con la conveniencia de un ambiente de desarrollo local. ¿Qué significa esto de combinar la nube con local? En el lado del cliente, Icenium expone un ambiente de desarrollo que puede ser una aplicación desktop (Mac o Windows) o un cliente web accesible desde cualquier navegador. Por otro lado, en la nube, Icenium expone los SDKs de Android e iOS. Es así que desde tu navegador puedes editar el código de tu app, simular su ejecución y mandar a compilar aplicaciones nativas (iOS y Android) que se compilan en la nube y que puedes descargar fácilmente cargar en tu teléfono simplemente direccionando a un QR code que Icenium te muestra en pantalla. Entonces, con Icenium no necesitas una Mac ni XCode para crear una aplicación para iOS. La programación en Icenium se hace usando HTML5, CSS y Javascript. Icenium utiliza las tecnologías Kendo UI y Apache Cordova (antes PhoneGap) para implementar el comportamiento de las apps y brindar acceso a capacidades como la cámara, acelerómetro y GPS.

Más info en http://icenium.com

—------------------

RethinkDB

NoSQL sencillo y sin limitaciones

RethinkDB es una base de datos tipo NoSQL que a grandes rasgos pretende brindar una simplicidad comparable a la de MongoDB pero sin sus limitaciones.

Entre sus capacidades están:

Modelo de datos JSON
Lenguaje de búsquedas intuitivo pero poderoso que soporta opciones complejas como table joins, subqueries, group by.
Map/reduce al estilo Hadoop.
Interfaz de administración amigable
Escalabilidad horizontal a un gran número de nodos.
Búsquedas paralelizadas automáticamente
Análisis de datos sin candados (lock-free) gracias a concurrencia tipo MVCC

Más información en http://rethinkdb.com

—--------------

Azure HDInsight

Hadoop para las masas

Como habíamos comentado anteriormente, Microsoft ha estado trabajando en ofrecer su versión de Hadoop para brindar capacidades de análisis de Big Data. HDInsight es la distribución Hadoop de Microsoft 100% compatible con Apache. HDInsight habilita a las organizaciones a analizar datos no estructurados al mismo tiempo que ofrece conectividad con las herramientas de Business Intelligence más populares. Aplicando una estrategia “muy Microsoft”, con HDInsight la empresa de las ventanas busca llevar el análisis de big data a un espectro amplio de usuarios, quienes podrán realizarlo desde herramientas familiares como por ejemplo Excel, PowerPivot, y Powerview. Así es, Hadoop desde Excel. HDInsight está disponible en dos modalides: como un software instalable en Windows Server, o como un servicio en Windows Azure.

Más información en http://swgu.ru/38r2

Bases de Datos En Memoria

lasr21 — Mon, 03 Dec 2012 10:13:31 +0000

Bases de Datos En Memoria lasr21 Mon, 12/03/2012 - 04:13

Publicado en

SG #38

Tendencias en Software

Los elementos fundamentales en el diseño de computadoras están cambiando, en particular el costo y aplicación de la memoria RAM. Esto nos da la oportunidad de reinventar la plataforma e infraestructura tecnológica.

La actual generación de sistemas de bases de datos relacional (RDBMS) está optimizada para almacenamiento en disco duro. Las bases de datos “en memoria” (in-memory) son un tema naciente, pero que cobrará gran popularidad durante los próximos años.

Factores clave

Velocidad. La ventaja principal de almacenar todo en memoria RAM es la velocidad. La velocidad de acceso a un disco duro ronda los 5 milisegundos mientras que en el RAM es de 80 nanosegundos, es decir una diferencia de cerca de 100,000 veces. Aún utilizando discos de estado sólido y memoria FLASH no-volátil, que es 100 veces más rápida que los discos duros tradicionales, estaríamos 1,000 veces más lentos que usando RAM.

Durabilidad. Pensar en la memoria como único almacenamiento genera la gran pregunta de qué es lo que sucede en caso de pérdida de poder. Para resolver esto, cada determinado tiempo (pocos minutos), las páginas de memoria RAM se escriben en almacenamiento no-volátil. Adicionalmente, las “transacciones” no se consideran completas sin que se haga permanente una bitácora (log) de la operación realizada. Es así que en caso de falla, se recupera la página más recientemente almacenada y se vuelven a aplicar las transacciones desde la bitácora.

OLAP En Memoria

Hoy las bases de datos se pueden optimizar para “procesamiento de transacciones” (OLTP) con almacenamiento en renglones o “procesamiento analítico” (OLAP) con almacenamiento columnar.

Las bases de datos transaccionales no son apropiadas para efectuar análisis, requieren índices. Una variación del modelo relacional son las estructuras multidimensionales que organizan datos expresando las relaciones entre los mismos. OLAP permite responder preguntas en 0.1% del tiempo requerido en ambientes transaccionales. La compresión es la máxima en este modelo, permitiendo almacenar “en memoria” grandes tablas, frecuente con un radio 1:10.

Hasta el día de hoy no existe ninguna estructura que permita indistintamente ser eficiente tanto en OLAP como OLTP —aunque algunos fabricantes lo estén publicitando así—. Lo mejor que se puede hacer hasta ahora en las bases de datos más modernas es especificar a nivel de tabla si se quiere almacenamiento en renglones o columnas.

Utilizar bases de datos “en memoria” permite reducir dramáticamente la cantidad de cubos pre-calculados a construir, porque es virtualmente instantáneo calcular cualquier consulta. Gracias a esto, podemos vislumbrar la eliminación completa de los cubos de información.

Un sistema “100% puro” en memoria puede ser diseñado para no depender absolutamente de las estructuras necesarias para operar con discos duros. Pero debido a la explosión de datos la mayoría de los sistemas serán “optimizados” para “en memoria” y se conectarán con bodegas de datos tradicionales o sistemas archivos distribuidos (v.gr. HDFS de hadoop) con información histórica.

La nueva inteligencia de negocio

Las nuevas herramientas de autoservicio en BI permiten que cualquier usuario pueda descubrir y analizar información empresarial. La expectativa es que el análisis de información se haga en tiempo real.

La clave para habilitar análisis instantáneo en un sistema en operación es reducir dramáticamente el tiempo requerido para transferir información OLTP a su forma OLAP. Hasta recientemente, este era un proceso muy tardado denominado “Extract, Transform, Load” (ETL). Pero en las bases de datos “en memoria” es posible sincronizar ambas estructuras con replicación basada en bitácoras.

Procesamiento complejo de eventos

Otro escenario de uso donde las bases de datos en memoria brindan una solución ideal, es en sistemas donde se reciben cantidades masivas de datos pero solo se requiere almacenar los cambios en éstos. Un ejemplo es monitorear millones de sensores de temperatura pero solo registrar aquellos en ciertos rangos, o con cierta variación. Conforme vaya aumentando la cantidad de dispositivos y sensores conectados al Internet que generan datos continuamente —lo que llaman el “Internet de las cosas”—, este será un escenario cada vez más común.

OLTP En Memoria

Con la versión 2012 de SQL Server, Microsoft liberó una tecnología llamada xVelocity, que provee capacidades “en memoria” para bases de datos OLAP. En la próxima versión de SQL Server, nombre clave Hekaton, xVelocity también se podrá utilizar en bases de datos OLTP. Esta tecnología consiste en “convertir” una tabla de SQL Server en una nueva tabla “en memoria” y en “compilar” a código máquina algunos procedimientos almacenados. El beneficio fundamental es que esto no requiere rediseñar la base de datos o aplicaciones, mientras que otras iniciativas de industria requieren una nueva arquitectura.

Esto acelerará dramáticamente el desempeño de los sistemas transaccionales. Como ejemplo, un sistema de venta de boletos que hoy requiere de 5 servidores para atender todas las peticiones en un tiempo aceptable, podrá ser reducido a uno solo. Esto simplifica dramáticamente realizar operaciones como cambio de precio de un producto, que se tiene que propagar de manera muy compleja en granjas de servidores. O permite obtener la escala de sistemas enormes en sistemas medianos.

Más allá de las mejoras en escalabilidad, xVelocity for OLTP permite vislumbrar escenarios totalmente nuevos en el mundo de base de datos. Algunos ejemplos:

“Procesamiento” de streams de datos. En el servicio de búsqueda Bing, la información se pre-procesa para ser colapsada y posteriormente almacenada; un “big data” puro sería demasiado costoso.
Cache. Una base de datos en memoria se utilizará para absorber stream de datos. Piense en un desastre natural y miles de llamadas telefónicas que generan rastros digitales
Baja latencia. Por ejemplo, el sistema del NASDAQ requiere una latencia menor a 0.5 milisegundos. Debido a la eliminación de contenciones en la tabla, esta métrica se puede cumplir sin soluciones especializadas con hardware disponible comercialmente.
Lectura de datos en escala masiva. Actualmente requerido por soluciones analíticas avanzadas o sistemas de juegos en línea.

Conclusión

Una estrategia completa “en memoria” deberá cubrir todos los tipos de carga (OLTP, OLAP, Procesamiento de eventos), estar disponible para PC, servidor o granjas de servidores. También debe poder ser adquirido en forma de software, como servicio o como appliance. Bienvenido a la nueva era de analíticos de grandes datos donde se acortan los ciclos para contestar a las interrogantes del negocio.

Bio

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

Consideraciones para Elegir a Tus Cofundadores

lasr21 — Mon, 03 Dec 2012 10:08:34 +0000

Consideraciones para Elegir a Tus Cofundadores lasr21 Mon, 12/03/2012 - 04:08

Publicado en

SG #38

Emprendiendo

Según Paul Graham, uno de los inversionistas más exitosos de Silicon Valley, dos causas comunes para el fracaso de un startup están relacionadas con los fundadores del proyecto: ser un fundador único (es decir no tener otros cofundadores) y peleas entre los cofundadores. ¿Cómo podemos evitar caer en estos errores? A continuación comparto algunas consideraciones.

El equipo correcto es más importante que el producto o el mercado. Para muchas personas pensar en con quién iniciar un startup puede tener poca importancia, sin embargo es uno de los pilares de cualquier proyecto. Tanto inversionistas como aceleradoras te dirán que a fin de cuentas, en quien se invierte es en las personas. Siempre será más sencillo ajustar tu estrategia, idea o modelo de negocio que encontrar nuevos cofundadores.

Conocerse desde antes es básico, tener historia juntos es mejor. En un startup se comparten momentos de incertidumbre y alegría por igual. Saber cómo reaccionan los demás ante el estrés, el miedo, la desesperación o el cansancio es imprescindible para saber si podrán trabajar juntos. Si las diferencias de actitud o formas de pensar son irreconciliables entre ustedes, se estarán peleando de manera constante, convirtiéndose en un problema mayor que los obstáculos mismos del proyecto.

Objetivos y estilo de vida alineados. Una de las causas más comunes de conflicto entre fundadores (y fracaso del startup) es no tener objetivos de vida similares. Iniciar un startup requiere mucho trabajo, esto significa trabajar una gran cantidad de horas, tener menos dinero para gastar y dedicar gran cantidad de tu espacio mental a pensar en el proyecto. Si alguno de los fundadores tiene un estilo de vida que le demanda tiempo o ingresos de manera muy desigual para los otros fundadores, es muy posible que se generen problemas.

Complementen sus habilidades y áreas de experiencia. Independientemente de la cantidad de cofundadores, lo más importante es que se complementen en sus áreas de trabajo. En mi experiencia, lo mejor es un equipo constituido por un programador, un diseñador y una persona de negocios; de esta manera avanzan en paralelo en las tres partes fundamentales del producto.

Es importante tener confianza, pero también hay que documentar. Es muy posible que durante el camino alguien deje el equipo, por lo que es importante documentar todo. Con documentar me refiero a: tener acceso a todos los archivos, servidores y recursos de negocio generados; llevar alguna documentación (aunque sea informal) de procesos y tecnologías; y por último firmar entre ustedes un documento donde se establezca qué pasará si alguno de los fundadores deja el equipo ¿Tendrá derecho a un porcentaje de la empresa? ¿Qué procedimientos se harán para la entrega?

Encuentren la forma de divertirse juntos. Busquen tiempo para platicar, para pasar tiempo de esparcimiento juntos y recordar por qué son el mejor equipo para llevar a cabo el proyecto. Celebren las pequeñas victorias.

Espero que consideres estos puntos al momento de llevar a cabo un nuevo proyecto. Te facilitarán el camino para tener un startup que avanza, aprende y construye rápidamente. Aunque como todos los consejos bien intencionados, siempre es más fácil ofrecerlos que seguirlos.

Bio

Celeste North (@celestenorth) es fundadora de NuFlick, plataforma de distribución de cine independiente y festivales de cine on demand enfocado en el mercado Latinoamericano. Organiza Founder Friday, un evento para fomentar el emprendimiento entre mujeres en la Ciudad de México. Es colaboradora editorial sobre temas de innovación y emprendimiento en Opinno, Emprendela y Software Guru.

Richard Stallman en México

lasr21 — Mon, 03 Dec 2012 10:04:31 +0000

Richard Stallman en México lasr21 Mon, 12/03/2012 - 04:04

Publicado en

SG #38

Entrevista

Richard Stallman, líder fundador de la Free Software Fundation y mundialmente conocido por el establecimiento de un marco de referencia moral, político y legal para el movimiento del software libre, estuvo en México durante el pasado mes de octubre para dar una "gira de conferencias". Durante el Encuentro Nacional de Software Libre (ENLi) en Puebla tuvimos oportunidad de asistir a su conferencia y estar presentes durante la ronda de preguntas y respuestas. Compartimos aquí un breve resumen.

Como era de esperarse, su arribo al auditorio fue bastante original, ya que entró diciendo “traigo pegantinas, tomen una”, así que todo el auditorio se abalanzó sobre las “pegantinas” (estampas) de logos de su fundación y frases de software libre. Cuando ya tenía a casi todo el auditorio de pie cerca de él, entonces sacó otras estampas y pines diciendo “traigo más cosas, pero éstas las vendo”.

Ya una vez terminada la venta matutina, comenzó su conferencia. El tema central de la conferencia fue la riqueza que brinda el conocimiento y cómo es un derecho para todos los seres humanos tener acceso a este sin restricciones. Recalcó que la importancia del software libre no es en relación al precio, sino a la disposición del conocimiento y a la disposición del código para que el software pueda mejorarse. “Las clases son espacios para compartir conocimiento y es en donde se debe de fomentar la libertad, es por ello que las universidades deben de enseñar con software libre”, comentó.

Entrevista

¿Qué sugieres que hagan los estudiantes para convencer a sus universidades de que enseñen con software libre?

Sugiero que se manifiesten, que exijan porque tienen el derecho de hacerlo. El software libre es un movimiento que necesita acción, y es responsabilidad de los estudiantes velar por sus libertades.

¿Has hablado con alguien del próximo gobierno de México sobre asuntos de libertad tecnológica?

Tuve reuniones con senadores y diputados. Les sugerí políticas del estado para migrar al software libre, que es lo que hace falta para recuperar la soberanía informática del país. Una dependencia pública hace sistemas de información para los ciudadanos, si pierde el control de éstos, está incumplimiendo con su responsabilidad. Si tú pierdes el control de tus sistemas, es una lástima para tí y diría “lo siento”, pero para una dependencia pública es mucho peor, porque afecta a sus ciudadanos. Pero sobre todo, la educación debe migrar al software libre, y el estado tiene la responsabilidad de asegurarlo.

Hablando sobre seguridad y protección de datos, al querer el Gobierno más control sobre los datos de la población con frecuencia hay más riesgo de que estos sean comprometidos, ¿qué opinas sobre esto?

Los datos que el Estado tiene, los tiene que proteger. Pero la protección más importante es que no recojan tantos datos personales. Si los datos se recogen se abusará de ellos. Así que el Estado debe de recoger menos datos.

¿Como podemos tener libertad en el contexto de la telefonía móvil?

El problema principal de los sistemas móviles es que nos vigilan, y no sé cómo evitarlo, porque el sistema de telefonía es capaz de ubicar el teléfono hasta sin su cooperación activa; comparando el tiempo de llegada de la señal a varias torres puede ubicar el teléfono aunque el teléfono no haga nada para ayudar. Esto me parece insoportable. Aunque había un teléfono móvil con GNU/Linux casi totalmente libre, cuando pensaba si tuviera uno cómo lo usaría para limitar la vigilancia a un nivel aceptable, no pude desarrollar un protocolo de uso. Tendría que preguntarme cuán frecuentemente y en qué tipo de lugar conectaría mi teléfono a la red de telefonía para aceptar llamadas. No pude llegar a una solución aceptable.

Otros comentarios

Uno de los alumnos le dijo a Stallman que el software privativo también da ventajas competitivas a sus usuarios, puesto que también son herramientas de trabajo y que incluso con frecuencia, son mucho más amigables, rápidas y fáciles de utilizar. Ante tal argumento Stallman esbozó una sonrisa diciendo “la libertad exige sacrificio”.

Al ser cuestionado sobre cómo lograr remuneración económica desarrollando software libre Stallman dijo que con donativos de usuarios satisfechos o donativos de personas que valoren el esfuerzo. Agregó: “Dar es la naturaleza humana, dar se siente bien, y yo me baso en la naturaleza humana”.

En fin, hablar de Stallman es hablar de un personaje controversial. Es una voz que puede llegar al extremismo, pero acarrea un mensaje que no podemos ignorar.

Marcando la Pauta para las Pruebas Ágiles

lasr21 — Mon, 03 Dec 2012 10:02:44 +0000

Marcando la Pauta para las Pruebas Ágiles lasr21 Mon, 12/03/2012 - 04:02

Publicado en

SG #38

Temas especiales

Dada su naturaleza, la industria del software enfrenta el enorme reto de mantenerse al ritmo de las cambiantes necesidades del mercado, la competencia y la globalización. Esto hace que la brecha entre la liberación de los productos de software y su comercialización se reduzca cada vez más, marcando con ello una dinámica de “puesta en producción” muy acelerada.

Las metodologías de desarrollo ágil han surgido intentando generar sistemas con alta calidad y a la vez, con una reducción y simplificación de tareas. Bajo este enfoque, las pruebas de software han tomado un papel crucial, dada la necesidad de realizar pequeñas liberaciones “funcionalmente” estables, surgiendo así el testing ágil. Para entender éste, es importante comprender cómo es que las pruebas encajan a lo largo de todo el ciclo de vida del desarrollo de software (SDLC). La figura 1 muestra un diagrama de Scott Ambler [1] que a grandes rasgos expone el ciclo de vida de desarrollo de software ágil.

Figura 1. Ciclo de vida de desarrollo ágil

El testing ágil refiere un enfoque dinámico de las pruebas de software. Dicho enfoque supone que los requerimientos no son estables sino que se incrementan de forma continua o se encuentran en constante cambio, de acuerdo a las necesidades expresadas por el cliente. Asimismo, el cliente también juega un rol muy importante manteniendo una comunicación cercana y continua con el equipo de desarrollo; la obtención de sus necesidades (requerimientos) no se considera como una fase separada del desarrollo del software, sino una parte integral del mismo.

Mientras que en las metodologías tradicionales las actividades de prueba normalmente se pueden iniciar hasta que la especificación de requisitos se encuentre completa, en el caso del testing ágil dichas tareas quedan inmersas dentro de cada iteración.

Por citar otra de las diferencias importantes entre las metodologías tradicionales de pruebas y las ágiles, podemos destacar que mientras las primeras tienen como objetivo primordial la validación del producto desarrollado, en las ágiles tiene gran peso su utilización como medio para guiar el desarrollo del software, sustituyendo así la definición formal de requisitos.

A continuación se presentan algunas prácticas y actividades de prueba, tomando en cuenta el enfoque ágil.

Identificar aspectos a probar. Considerar las siguientes preguntas como guía para el desarrollo de los casos de prueba:

¿Qué necesidades del usuario debe resolver este producto?
¿Cuáles son las más críticas desde el punto de vista del usuario? (relación con pruebas de aceptación).
¿Cuál es el comportamiento esperado? ¿Cuál es la secuencia de acciones? (historias de usuario)
¿Hay alguna dependencia especial en el sistema?
¿Existen requerimientos no funcionales? ¿Cuáles?
¿Cuáles son las limitaciones del software/hardware respecto a características, funciones, datos, tiempo, etc.?
¿Las descripciones son lo suficientemente completas para decidir cómo diseñar, implementar y probar cada requisito y el sistema en sí como un todo?
¿Qué problemas y riesgos pudieran estar asociados con estos requisitos?

Definir el alcance de pruebas. Éste tiene que encontrarse perfectamente delimitado por cada uno de los entregables solicitados por el cliente en cada iteración. Puede identificarse respondiendo a las preguntas:

¿Qué necesidades del cliente van a ser incluídas en esta liberación?
¿Cuáles van a excluirse de las pruebas en este producto específico?
¿Qué es lo nuevo en esta liberación con respecto a otras?
¿Qué ha cambiado o se ha actualizado/corregido para este producto?

Identificar las métricas de pruebas. Elegir las métricas que se van a utilizar para dar seguimiento a los objetivos asociados a cada liberación.

Definir los niveles de pruebas que se aplicarán. Por ejemplo: unitarias, de integración, de aceptación.

Definir los tipos de prueba que se realizarán. Por ejemplo: funcionales, de carga, stress, seguridad, etcétera.

Definir estrategias de pruebas.

Identificar las técnicas utilizar. Ejemplos: Pruebas exploratorias, Pruebas basadas en Riesgos, Pruebas automatizadas, etc.
Identificar las herramientas de ejecución y de administración de pruebas usar, buscando principalmente aquellas cuyas plantillas de registro de defectos (por ejemplo), sean lo más simples y concisas posible, evitando trabajo redundante y exhaustivo; en el caso de herramientas de automatización, dependerán del lenguaje.
Realizar la selección de los datos de pruebas.
Definir cómo se va a preparar y configurar el ambiente de pruebas.

Definir el punto de terminación de las pruebas.

¿Cuándo continuar o detener las pruebas antes de entregar el sistema al cliente?
¿Qué criterios de evaluación deben cubrirse?
¿Qué criterios finales de aceptación deberán satisfacerse?

Pruebas de aceptación y ATDD

Las diversas metodologías ágiles (Scrum, eXtreme Programming, etcétera) de algún modo han promovido la aplicación de las pruebas, dado que éstas son indispensables para la liberación exitosa (con calidad) de cada entregable; con ello también se han diversificado las estrategias para abordar dichos proyectos. Es así que han ganado popularidad estrategias como el Desarrollo Dirigido por Pruebas (TDD -Test Driven Development) y el Desarrollo Dirigido por Pruebas de Aceptación (ATDD - Aceptance Test Driven Develepment).

Sobre este último enfoque, ATDD, algunos aspectos clave a mencionar son los siguientes:

Toma como principal referencia al usuario final, al cliente.
Utiliza historias de usuario como requisitos a los que se asocian pruebas de aceptación (escenarios).
Las pruebas de aceptación dirigen el diseño/desarrollo del sistema, ver Figura 2.
Requieren entrar tempranamente en detalles de implementación e instanciación de datos de pruebas

Figura 2. Proceso general de Desarrollo Dirigido por Pruebas de Aceptación.

De acuerdo al diccionario de la IEEE, cuando hablamos de pruebas de aceptación nos referimos a “aquellas pruebas formales con respecto a las necesidades, requerimientos y procesos de negocio del usuario, conducidas para determinar ya sea si un sistema satisface o no los criterios de aceptación y habilita al usuario, cliente o entidad autorizada para determinar si el sistema se acepta o no” [2].

Como ya decíamos, en ATDD cada necesidad del usuario final se representa a través de historias de usuario (al igual que en TDD, donde la base son las pruebas unitarias), y a su vez cada historia de usuario tiene asociados ciertos criterios de aceptación. Para cada criterio se deben diseñar los respectivos escenarios/pruebas de aceptación que deberán aprobarse; una vez que éstas pruebas han sido diseñadas, los desarrolladores comenzarán a programar el código fuente que permitirá satisfacerlas; por su lado los desarrolladores definirán las pruebas unitarias que evaluarán el cumplimiento de los requisitos (expresados en términos de criterios de aceptación).

Vale la pena reiterar que las Pruebas de Aceptación son sólo el medio para probar la funcionalidad del sistema, pero ATDD representa todo el proceso de desarrollo cuya finalidad es que el sistema se construya de acuerdo a la funcionalidad expresada por el usuario. Por eso es que las pruebas de aceptación se definen en lenguaje natural, de modo que puedan ser comprendidas por los usuarios o analista de negocios del cliente.

Al igual que la definición de cualquier escenario de prueba, se plantea que contenga como mínimo: Título, pre-requisitos / precondiciones, descripción/pasos, criterios de aceptación/resultado esperado, tipo de usuario.

Automatización

Una vez que hemos diseñado todas las pruebas de aceptación que cubrirán todos los criterios que serán avalados por el cliente, podemos proceder a su automatización en alguna herramienta de pruebas para tal objetivo, teniendo posibilidad de elegir entre varias en el mercado, desde algunas gratuitas con sus respectivas limitaciones, hasta aquellas más completas y/o complejas que se ofrecen para compra o en la nube, soportando diversas tecnologías, protocolos, sistemas operativos: Selenium, soapUI, TOSCA testsuite, HP Quick Test Pro, SilkTest, IBM Rational Functional Tester, SOATest, TestPartner, Visual Studio Test Profesional, etc.

La automatización en sí ciertamente nos ayudará a agilizar la ejecución de dichas pruebas de aceptación, sin embargo es de considerar también el mantenimiento que dichos scripts de prueba requerirán, máxime cuando de antemano sabemos que los requerimientos cambiarán continuamente, de ahí que el tema de la automatización de pruebas juega un papel crucial en un marco de trabajo Ágil.

En mi particular punto de vista, se debería hacer una análisis de los costos asociados con el mantenimiento de código que implícitamente se tendrá con la automatización y evaluar a conciencia qué partes de la aplicación convendrá probar bajo esta técnica y cuáles no, pues quizás en otros casos pueda resultar más efectiva alguna otra técnica como las mismas pruebas exploratorias manuales, realizadas por supuesto por ingenieros de pruebas con la mayor pericia o experiencia posible.

Perfil del tester

El aspecto humano no debe dejar de analizarse. El personal de pruebas definitivamente debe contar con las siguientes características:

Excelentes habilidades de comunicación (de vital importancia por toda la interacción que se da entre los miembros de los equipos).
Pasión y entusiasmo por las pruebas.
Muy fuertes habilidades de trabajo en equipo, no individualismo.
Programación en lenguajes de scripting.
Habilidad para trabajar bajo presión (constantes entregas rápidas).
Liderazgo.

Si bien es cierto, las habilidades anteriormente señaladas, no sólo debieran estar presentes en testers de proyectos de pruebas ágiles, sino en cualquier ingeniero de pruebas. Sin embargo, para este tipo de proyectos podríamos casi decir que son “las imperdonables”, dada la dinámica con la que se suele trabajar.

Conclusión

En mi opinión, no buscaría decidir cuál metodología es mejor, sino más bien buscaría identificar claramente cuándo aplicar alguna y cuándo otra, dado que los proyectos son cambiantes, son diferentes en muchos aspectos, entre ellos en tamaño, en complejidad, etc. Toda esa serie de elementos nos permitirán definir si las metodologías ágiles son aplicables o no en cada caso. Creo también que puede incluso presentarse un híbrido de metodologías ágiles y convencionales, teniendo por supuesto muy claro cómo sacar mayor ventaja a los elementos que una y otra ofrecen.

Bibliografía:

[2] [IEEE 610] IEEE Std 610-1991, IEEE Computer Dictionary – Compilation of IEEE Standard Computer Glossaries, IEEE.

Bio

Sandra Berenice Ruiz Eguino es Directora de Operaciones de e-Quallity, además ha participado como Consultora Senior en proyectos de mejora de organizaciones de Prueba de Software. Cuenta con certificación internacional en Pruebas por el ASTQB. A lo largo de su trayectoria profesional ha actuado también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciencias Computacionales.

Pruebas y el Ciclo de Vida Ágil

lasr21 — Mon, 03 Dec 2012 09:57:33 +0000

Pruebas y el Ciclo de Vida Ágil lasr21 Mon, 12/03/2012 - 03:57

Publicado en

SG #38

Temas especiales

Aplicar los principios de los métodos ágiles al ciclo de vida de las pruebas permite mantener y mejorar su velocidad, la documentación, reutilización de casos de prueba, así como también la capacidad de repetir y automatizar las mismas.

Por otro lado, las mejores prácticas en el ciclo de vida del desarrollo de las aplicaciones indican que el ciclo de vida de las pruebas debe iniciar en el momento que los requerimientos han sido finalizados, esto permite que las pruebas sean basadas en las solicitudes iniciales del usuario/cliente y no ejecutadas sobre aquellas funcionalidades que el equipo de desarrollo generó, porque no necesariamente podría ser lo mismo.

Este inicio temprano del ciclo de vida de las pruebas sirve para aplicar uno de los principios de administración de la calidad: “empezar a probar temprano y probar más”. En consecuencia, tener más resultados de pruebas permitirá maximizar la probabilidad de encontrar errores.

Las pruebas en el ciclo de vida ágil

Dado que las pruebas deben de formar parte integral del ciclo de vida del desarrollo de las aplicaciones, el flujo de proceso ideal debería ser el siguiente:

1. Requerimientos. Conforme los requerimientos, o solicitudes de cambio, van siendo definidos, revisados y autorizados, cada uno de ellos sirve como entrada para definir los casos de prueba con los que estos requerimientos serán cubiertos y probados.

2. Planeación y diseño. Con base en la planeación de las actividades de construcción y codificación de las aplicaciones, que a su vez ha tenido como entrada aquellos requerimientos adecuadamente priorizados y asignados a la iteración actual, es posible para el equipo de pruebas ir planeando e iniciar el proceso de aprovisionamiento del ambiente de pruebas. De igual manera, la planeación inicial de las pruebas, permitirá identificar aquellos casos, previamente creados y/o utilizados, que sean similares y que puedan ser reutilizados. Lo más importante, es que el equipo de pruebas no necesite “descubrir el agua tibia” con cada prueba que se requiera, y únicamente dedicar el tiempo a crear los pasos necesarios para validar las deltas que existen entre la aplicación anterior con la aplicación futura basada en las modificaciones que se estén creando en la iteración actual.

3. Ejecución. Conforme se implementan las piezas funcionales de código, los casos de prueba son ejecutados contra éstas, validando que el requerimiento original esté cubierto e implementado. A partir de los resultados de las pruebas se generan los protocolos pertinentes ya sea de aceptación de las piezas o la documentación de las solicitudes de mejora en forma de reportes de defectos o cambios.

4. Retroalimentación del proceso. Con el paso anterior, se generan nuevas entradas a la planeación de actividades de construcción y codificación, creando un macro-ciclo a través de las diferentes disciplinas del ciclo de vida del desarrollo de las aplicaciones.

Agilizando las pruebas

Un factor fundamental para mantener la agilidad de las diversas actividades de las pruebas, está basado en el ejercicio amplio y abierto de la colaboración entre los diversos equipos. La colaboración propuesta debe permitir el intercambio de la documentación intrínseca que se va generando durante el proceso de madurez de los artefactos e interacciones entre los diferentes actores del proceso de desarrollo de las aplicaciones. De esta manera, se satisface uno de los principios de las metodologías ágiles, “documentación mínima necesaria”.

Para aceptar el “cambio como una constante”, es necesario poder identificar y analizar fácilmente el impacto de los cambios a través de todo el ciclo de vida del desarrollo de las aplicaciones. Esto se logra conociendo: las actividades de construcción y codificación que están incluidas en una iteración, los casos de prueba que validan cada uno de los requerimientos, y los resultados de las pruebas ya que afectan la planificación de las actividades en la iteración actual y futuras.

Para poder hacer más sencillos estos procesos complejos que involucran equipos, prácticas y disciplinas diversas, es necesario poseer herramientas y/o repositorios donde la información, documentación y resultados estén disponibles para todos los equipos.

Hablar de pruebas en el contexto de desarrollo ágil me recuerda la premisa que plantea Eric S. Raymond en su ensayo “The Cathedral and the Bazaar”:

Bio

Germán Domínguez (germand@mx1.ibm.com) es Client Technical Professional para IBM Rational en México desde el 2008. Tiene 17 años de experiencia en desarrollo de aplicaciones de negocios, consultoría de procesos y lenguajes de programación. Actualmente apoya a diversos clientes con estrategias de modernización empresarial, application lifecycle management, arquitectura empresarial y herramientas de desarrollo.