Posts Tagged ‘ingenieria’

h1

E.T. nos dio la Wi-Fi: ¿Es posible adoptar tecnología extraterrestre?

06/24/2016

Space [Icon By Buuf]
 SETI.

Toda tecnología lo suficientemente avanzada es indistinguible de la magia.

Arthur C. Clarke (1907 – 2008). Escritor británico de divulgación científica y ciencia ficción.

Justo el día de hoy, la secuela del aclamado filme de ciencia ficción, Independence Day (1996), se estrenó en Hispanoamérica. Titulada como Independence Day: Resurgence, esta nueva entrega nos cuenta lo que ocurre 20 años después de la fallida invasión extraterrestre mostrada en la primera película. El argumento se centra en qué ocurre cuando los alienígenas remanentes en la Tierra logran enviar una señal de auxilio al resto de su flota, esparcida por el resto de la galaxia. Así como las demás producciones de su tipo, seremos testigos de un ejemplo clásico del Blockbuster Hollywoodense, que usualmente cuenta con una relativa simplicidad de guión, uno o dos personajes memorables y unos extraordinarios efectos visuales.

Sin embargo, un punto peculiar del filme consiste en que los humanos han logrado recuperar, estudiar y aplicar tecnología extraterrestre. ¿Es esto realmente posible? Porque si bien infinidad de series y películas de ciencia ficción muestran cómo la humanidad logra prevalecer o congeniar con otras civilizaciones debido a que las diferencias tecnológicas se reducen a “ametralladoras frente a láseres”, la realidad es que muy pocas historias explican cómo nuestros valientes científicos e ingenieros estudian estos “campos de fuerza”, para posteriormente copiarlos y colocarles el sello de “Hecho en la Tierra”.

Cualquier tecnología extraterrestre a nuestro alcance no puede ser el resultado de una invasión, ya que de manera realista, si un imperio galáctico quiere deshacerse de los terrícolas, éste no requiere de contacto alguno con nosotros. Con algo tan burdo como un asteroide de hierro de unos 10 Km de diámetro, viajando al 90% de la velocidad de la luz, es posible desintegrar el planeta – y con sólo una milésima parte de esa velocidad, es posible eliminar a casi toda la vida en la Tierra. Por lo tanto, para tener algo recuperable y vivir para contarlo, cualquiera de los siguientes escenarios debería ocurrir:

• Un accidente en cualquiera de los planetas o lunas de nuestro sistema solar, que por lo menos permita la recuperación parcial de los restos. Por ejemplo, un choque a menos del 0.01% de la velocidad de la luz, o unos 30 Km/s. Dichas velocidades son ciertamente catastróficas para los tripulantes y el planeta huésped (equivalentes a una explosión nuclear de miles o millones de megatones, como el que extinguió a los dinosaurios hace 65 millones de años), pero debido a los requerimientos técnicos necesarios para el viaje interestelar, es posible que quede algo qué rescatar.

• Descubrimiento de instalaciones o artefactos alienígenas abandonados en nuestro sistema solar. De acuerdo a la Paradoja de Fermi, de existir vida extraterrestre, la Tierra sería visitada una vez cada 2 millones de años, por lo que es probable que hayan dejado algo atrás, pero es muy difícil de detectar: debido a las fuerzas erosivas y geológicas de nuestro mundo, tales dispositivos deberían haber sido destruidos desde hace mucho tiempo – no así para los lugares con atmósfera inexistente y órbitas estables, como algunos asteroides, lunas y planetoides del sistema solar.

Pic: 300 Million-year UFO Gear! (Not really)


Un artefacto metálico que parece ser parte de un engrane, encontrado en un depósito de carbón de 300 millones de años de antigüedad en la región de Jakasia, Rusia Meridional. Manteniendo una postura de escepticismo, esto también puede ser un cristal de ferrita, un fósil de crinoideo o una parte del equipo de minería que pudo haberse roto durante la extracción del carbón. (Fuentes: The Huffington Post y Doubtful News)

¿Es posible descifrar su operación y funcionamiento?

Lamentablemente, a diferencia de un mensaje desde las estrellas, cualquier maquinaria extraterrestre encontrada de esta manera estaría incompleta o en un terrible estado de deterioro: recordemos que para copiar un mecanismo, es necesario verlo en funcionamiento; de lo contrario sólo podremos hacer conjeturas acerca de su operación. Un ejemplo de esto es el Mecanismo de Anticitera, recuperado del fondo del Mar Mediterráneo en 1900.

Por mucho tiempo, dicho mecanismo fue considerado como la prueba absoluta de visitantes extraterrestres, pues se creía que era tecnológicamente demasiado complejo como para haber sido construido por seres humanos. Cabe mencionar que su fecha de ensamblado se estimó en base a los sedimentos formados alrededor del mecanismo, así como otras piezas de arqueología encontradas en el mismo lugar de su descubrimiento: entre el 150 y el 100 antes de nuestra era. No fue sino hasta finales del 2006 que se encontró su verdadera función: ésta es una computadora análoga usada para predecir posiciones astronómicas y eclipses con fines calendáricos y astrológicos. Es decir, se requirieron más de 100 años para descubrir que un mecanismo incompleto de engranes de cobre fue construido por humanos para algo tan pedestre como saber cuándo se jugarían los Juegos Olímpicos.

Por otro lado, es necesario considerar que cuando se trata de tecnología avanzada, es muy probable que el gobierno o fabricante original haya incluido algunas salvaguardas para evitar que su tecnología sea replicada. Esto hace mayor sentido con desarrollos gubernamentales – como una sonda interestelar probablemente lo sería – ya que viéndolo desde el punto de vista de un terrícola, muchos grupos a lo largo de nuestra historia han tratado de robarse o copiar la tecnología de los demás, desde que un homínido se dio cuenta que un hueso podría ser una eficiente herramienta de cacería, o una poderosa arma para tomar el abrevadero de la tribu vecina.

El problema del costo

Hay una relación inversa entre la existencia y adopción de una tecnología determinada y su coste unitario; mientras más instancias de ella se implementan, más se aprende cómo producirla de manera barata y eficiente, lo que significa que su costo al público puede ser reducido sin disminuir el margen de ganancia. Así, tecnologías recientemente desarrolladas que no han tenido el tiempo suficiente para dejar que esta relación tenga efecto, tienden a ser muy costosas de adquirir y difíciles de mantener. Un ejemplo de esto son los automóviles eléctricos: en 2003, el Tony Stark/Iron Man de la vida real, Elon Musk, fundó Tesla Motors con el objetivo de revolucionar la industria automovilística; a sabiendas de que esta tecnología era demasiado costosa, su estrategia se centró en primero ingresar al mercado con un modelo caro, apto sólo para clientes VIP: en 2008 inició la producción del Tesla Roadster, por un precio de US$109,000. Conforme los volúmenes de venta han aumentado, los modelos han evolucionado de la misma manera: hoy por hoy, existe el Modelo 3, revelado al público en 2016 con un costo de US$35,000. Se espera que en dos o tres años más, se terminará el desarrollo del modelo Gen 4, con un precio asequible para la mayoría de la población.

Así, la adquisición de tecnología avanzada requeriría no sólo de entenderla y replicarla, sino que también implicaría la creación de nuevas industrias, procesos y modelos de negocio para que pueda ser adoptada por todos. Esto conllevaría considerable tiempo y una enorme inversión, por lo que lamentablemente, a veces tarda mucho o no termina de suceder debido al statu quo: no fue sino hasta que Tesla demostró un éxito sostenido, que otras compañías automotrices se han unido de mala gana a esta corriente.

Por supuesto, cualquier argumento en contra de los costes de producción pierde su validez en cuanto a la tecnología militar se refiere. Sólo tenemos que superar algunas “pequeñas” limitaciones técnicas, para las que todavía no hemos descifrado completamente la solución…

El problema del software

Para los que tienen un mínimo conocimiento en TI: ¿alguna vez vieron precisamente, Independence Day? ¿Cuál es la escena más atroz que llegaron a ver en dicha película?

Pic: A PowerBook communicating with an alien computer


Precisamente. (Fuente: Reddit)

La mera idea de que una Mac, ensamblada hace 20 años, sea compatible con el sistema operativo de una nave extraterrestre de más de 500 kilómetros de diámetro, miles de años más avanzada de lo que la humanidad jamás ha creado, y lo suficientemente sofisticada como para darle soporte vital a toda una civilización extraterrestre, es considerado por cualquier ingeniero de software como una de las peores representaciones de la informática en la historia del cine. Si tomamos en cuenta que la última laptop ofertada por Apple tiene mil veces la cantidad de memoria RAM de la laptop mostrada en la película, sería realmente chusco ver a alguien intentar conectarlas; incluso más si consideramos que ambas son del mismo fabricante.

Ahora bien, una de las realidades de la vida moderna es que el futuro casi no consistirá de materiales nuevos, sino que estará basado en cómo combinar materiales ya conocidos y hacerlos funcionar. Un celular está compuesto de plástico y algunos metales (oro, cobre, plata y litio); pero lo que realmente lo hace útil es el complejo software que le permite funcionar: con él, es posible usar 4G para navegar por internet, llamar a otros dispositivos celulares, o sincronizar la información contenida en el dispositivo con un wearable o aplicaciones en la nube.

Intentar extraer y decodificar este software es posiblemente uno de los mayores obstáculos para aplicar ingeniería inversa a un artefacto extraterrestre, ya que sería indispensable conectarse a dicho dispositivo y descargar el sistema operativo para descifrar sus rutinas. Por supuesto, si bien esto es muy difícil, no es imposible: incluso hoy existe gente alrededor del mundo cuyo hobby consiste en descargar el software de sus propios automóviles para hackearlos y optimizar su desempeño. Hacer lo mismo con un dispositivo cuya arquitectura, lenguaje de programación y abstracciones son desconocidas, podría tomar décadas y considerable poder de procesamiento, pero de lograrse, eventualmente obtendríamos las llaves del reino.

El problema de la energía

Desde la década de 1990 aparecieron experimentos científicos que demuestran la posibilidad de crear ventanas de plasma, que separan el vacío del espacio exterior, del interior de una nave espacial. También, ya existen en la actualidad diseños que permitirían enviar sondas a Alfa Centauro en tan sólo cinco años o a Marte en apenas 7 minutos. ¿Que es lo que impide que estas fantásticas tecnologías se hagan realidad, aparte de los elevados costos?

El traje de Iron Man es un extraordinario exoesqueleto que permite entre otras cosas, cargar objetos de varias toneladas de peso, volar a la misma velocidad que un avión caza y disparar ráfagas de plasma. Su potencia estimada es de 4 millones de caballos de fuerza, o 2.98 Gigawatts/hora, equivalentes a 2.2 veces la energía generada por una planta nuclear como Laguna Verde, México. Lamentablemente, hoy por hoy no contamos con una fuente de energía del tamaño del reactor arc (un reactor de fusión fría del tamaño de una mano) mostrado en los comics y las películas.

Así entonces, la miniaturización de fuentes de energía es otro problema al que se enfrentan los ingenieros, y por el que no pueden pasar de pequeños experimentos en el laboratorio: para hacer funcionar estos increíbles gadgets, es necesario crear y almacenar enormes cantidades de energía en un espacio muy reducido. Algunos materiales tienen la densidad de energía necesaria (por ejemplo, para el traje de Iron Man bastan 133 gramos de uranio en un reactor reproductor), pero entonces, nos enfrentaríamos al obstáculo final para la adopción de tecnología extraterrestre: nuestra propia biología.

El problema de la biología terrestre

Todos hemos soñado alguna vez con tener un auto volador desde que éramos niños. Y cuando aprendimos a manejar, llegó algún momento en que incluso de adultos, hemos dejado correr la imaginación: si estamos atorados en el tráfico pesado de la hora pico, nos imaginamos despegando en modo vertical para volar a casa o al trabajo dejando atrás el smog, el ruido y la incomodidad. Excepto que esto es imposible.

Incluso en la actualidad, existen “carreteras” por el aire que todo piloto de avión debe seguir, y si llega a darse tráfico aéreo pesado, deben volar sin cesar en un patrón de círculo hasta que haya un lugar disponible en la pista de aterrizaje. Entonces imaginémonos no sólo una hilera de automóviles enfrente y atrás de nosotros durante la hora pico, sino varios niveles arriba y abajo también. Si ocurre una descompostura o un choque en el aire, no podremos detenernos en el acotamiento para llamar a la compañía de seguros, sino que caeremos por varios cientos o miles de metros hacia abajo, llevándonos a una muerte segura a todos los que estén circulando debajo de nosotros en ese momento, y a los que estén a nivel del suelo también.

El punto es que nuestra tecnología también viene de la mano de características de seguridad: si bien es posible crear reactores nucleares del tamaño de una batería de automóvil, o sondas que viajen a Marte en 7 minutos, nuestros cuerpos no están a la par de estas tecnologías, por lo que sufriríamos de daños irreparables o una horrible muerte; ya sea por la radiación, altas velocidades o exposición al frío y calor extremos. Con decir que el simple hecho de estar en una nave espacial, es mortal para los seres humanos.

Posiblemente, para adoptar cualquier clase de tecnología futura (y no sólo la extraterrestre) tendremos que cambiar nosotros mismos también. Con mejoras genéticas y cibernéticas, eventualmente será posible salir allá afuera. Pero de momento, adaptar o crear tecnología que hoy es indistinguible de la magia, dependerá enteramente de qué tan segura es para formas de vida basadas en carbono con una baja resistencia a la variación de temperatura, presión o fuerzas centrífugas. Como elocuentemente menciona uno de los personajes de la serie de televisión Battlestar Galactica (2004):

¡No quiero ser humano! Quiero ver los rayos gamma. Quiero poder escuchar los rayos X. Y quiero – quiero oler la materia oscura. ¿Ves lo absurda de mi existencia? ¡Ni siquiera puedo expresar estas cosas correctamente, ya que tengo que – tengo que conceptualizar ideas complejas en este estúpidamente limitado lenguaje hablado! Pero sé que quiero alcanzar con algo más que estas patas prensiles. Y sentir el viento solar de una supernova fluyendo sobre mí. ¡Soy una máquina! ¡Y puedo saber mucho más! Puedo experimentar mucho más. ¡Pero estoy atrapado en este cuerpo absurdo!

— John Cavil/Número Uno. Battlestar Galactica (2004).

Conclusiones

Algunas de las historias de ciencia ficción más entretenidas tienen que ver con la adopción de tecnología extraterrestre, principalmente para que el conflicto no se convierta en una lucha sin esperanza para los seres humanos. Incluso algunas historias expresan la jocosa idea de que nuestra tecnología moderna, como el velcro, los hornos de microondas o la liposucción, es producto de ingeniería inversa aplicada a platillos voladores. Sin embargo, suponiendo que tenemos acceso a dicha tecnología para estudiarla, esta tarea requeriría un esfuerzo titánico, por decir lo menos. Un ejemplo de la vida real: en la década de los 1960, la NASA creó los Saturno V, unos cohetes que nos permitieron llegar a la Luna, y son considerados una de las más impresionantes hazañas de ingeniería de todos los tiempos. En 2004, la agencia espacial norteamericana buscó replicar su potencia como parte del Proyecto Constelación, pero no fue posible hacerlo, debido a que la infraestructura con la que se construyeron estos cohetes ya no existe. Se estima que se necesitarían dieciséis mil millones de dólares (US$16,000,000,000) para recrear las industrias y procesos requeridos por el Saturno, más quinientos cincuenta millones de dólares (US$550,000,000) por lanzamiento. Por esos precios, es mucho más sencillo crear desde cero versiones que sean igualmente potentes, aunque más ligeras, fuertes y hasta reutilizables – algo que de hecho, están tratando de lograr empresas como Blue Origin y SpaceX.

Así entonces, la ciencia ficción eventualmente se volverá realidad, haciendo innecesario importar tecnología de “hombrecillos verdes”. El problema principal es el tiempo que nos tomará llegar hasta ahí, debido a la interacción de factores como la continua evolución de la ciencia, cuáles son sus costos de implementación y qué tan segura o deseable puede llegar a ser. Después de todo:

Sólo aquellos que intentan lo absurdo alcanzarán lo imposible.

M. C. Escher (1898 – 1972). Dibujante y litógrafo holandés.

h1

Cómo hacer Pruebas de Concepto (POC): un enfoque formal

04/29/2016

Wizdoc [Icon By Buuf]
 Tips & Tricks.

El verdadero viaje del descubrimiento no consiste en buscar nuevos paisajes, sino en tener nuevos ojos.

Marcel Proust (1871 – 1922). Novelista, ensayista y crítico francés.

Supongamos que nuestro equipo ha estado trabajando durante varias semanas / iteraciones / sprints y todo se ve bastante bien. Sin embargo, el cliente nos pide desarrollar un tipo de requerimiento que nunca hemos hecho anteriormente o del que no estamos seguros cómo implementarlo. ¿Qué hacer cuando el equipo debe enfrentarse a una cuestión técnica o funcional desconocida?

Con frecuencia, los proyectos TI se desenvuelven en un ambiente caótico, para el que es necesario resolver una serie de requerimientos funcionales a través de soluciones tecnológicas que conllevan un cierto riesgo durante su implementación. Para minimizar este riesgo, es necesario llevar a cabo lo que comúnmente conocemos como prueba de concepto (Proof of Concept – POC) o spike – este último, surgido del desarrollo de software ágil. Esta actividad consiste en la construcción de una maqueta o demo con la finalidad de evaluar la factibilidad de un requerimiento funcional vagamente especificado, el desarrollo de un componente de software, la adquisición de un producto, o una combinación de todos ellos. En resumen, cada vez que encontremos requerimientos que posean demasiada complejidad técnica o un fuerte grado de incertidumbre, es necesaria una POC para determinar su factibilidad e impacto. Sin embargo, es necesario recordar que todo requerimiento posee un cierto grado de incertidumbre y riesgo, por lo que las pruebas de concepto deben ser una excepción, no la regla: para los riesgos e incertidumbres “menores”, el equipo debe descubrir la solución mediante el debate, la colaboración, la experimentación y la negociación. Una POC o spike por el contrario, debe reservarse para problemas importantes y complicados de responder. Por ello:

• La prueba debe evaluarse de acuerdo a objetivos claramente definidos entre todos los stakeholders, incluyendo mínimamente, qué medir (funcionalidad de negocio, funcionalidad TI, funcionalidad de sistemas), cómo medirlo (costo, facilidad de uso, escalabilidad) y cómo se realizará la evaluación (a través de un scorecard, escenarios de uso).

• Asimismo, debe tener un tiempo definido (timebox), para hacer el suficiente trabajo como para obtener el valor requerido.

• Finalmente, la prueba debe ser parte integral de la estrategia de implementación del proyecto, habiendo sido debidamente planeada y documentada, incluyendo el tiempo y esfuerzo necesarios para su análisis, diseño e implementación.

Pic: Wright Brothers' Prototype Designs


Cuando Wilbur y Orville Wright perfeccionaron su aeroplano, decidieron probar sus teorías antes de sujetarse a sí mismos sobre el ala de una máquina voladora. Usando modelos a escala en túneles de viento, hicieron pruebas sobre la factibilidad del vuelo tripulado.

Iniciando en 1900, éste fue su primer prototipo, que básicamente era un papalote o cometa. Con él, probaron la idea de deformar la parte superior del ala para controlar el balanceo de la aeronave. Entonces construyeron un planeador en 1901. Este avión volaba como una cometa, pero también podía desempeñarse como un planeador pilotado. Los hermanos Wright ganaron experiencia de vuelo con este avión, descubriendo a la vez varios problemas que tuvieron que superar más tarde, como mayor resistencia al aire y la tendencia a voltearse en pleno vuelo. Después vino el aeroplano de 1902, que fue el primer avión en el mundo que podía ser controlado sobre sus tres ejes (transversal, horizontal y longitudinal). Finalmente, en 1903 construyeron su Wright Flyer: una aeronave pilotada que podía despegar y volar por sus propios medios.

Así, sucesivas pruebas de concepto cumplieron su propósito, dando a los hermanos Wright los datos necesarios para validar que sus objetivos e ideas tenían suficiente mérito como para continuar. Se demostró que la teoría podría funcionar en conjunto con otros factores integrales, como la experiencia necesaria para controlar un avión, materiales de construcción y requerimientos climatológicos.

(Fuente: NASA)

Mejores Prácticas

Una prueba de concepto no debe ejecutarse de manera aislada del resto de la organización TI; ésta debe contar con el apoyo de las áreas relacionadas a su implementación, tales como los usuarios de negocio, proveedores, infraestructura y soporte técnico. Esto porque cualquier retraso durante la ejecución puede volverse crítico. Adicionalmente, es buena idea seguir las siguientes mejores prácticas:

• Limitar el alcance. La solución debe evaluarse contra escenarios representativos; no todos los escenarios de uso. En caso de estar evaluando la adopción de un producto, debemos indicar al cliente de que ésta correrá en las plataformas estándar y usadas por clientes existentes. Asimismo, es muy importante no añadir alcance adicional a la POC, a menos que éste sea obligatorio para el éxito de ésta, y haya sido acordado por todos los stakeholders, incluyéndonos a nosotros.

• Planear con anticipación. A menudo, esta será la primera vez que varias organizaciones, incluyendo terceros, estarán trabajando juntos. Es indispensable asegurar que todos puedan comprometerse a los plazos definidos por la POC. También es importante alinear las reuniones de avance antes de tiempo. Los usuarios usualmente tienen sus actividades del día a día, y los cierres trimestrales o anuales pueden comprometer su disponibilidad para revisión o apoyo.

• Ejecutar la prueba de manera aislada al resto del ambiente productivo. A menos que la integración sea crítica, la conectividad con otros sistemas debe ser simulada. Esto porque casi siempre, obtener los permisos necesarios para integrar la maqueta a otros sistemas informáticos se convierte en todo un reto.

• Mantener a los stakeholders informados con regularidad sobre el progreso de la prueba. Cuando llega el momento de selección y/o evaluación, todos los interesados deben estar alineados a los resultados. Esta alineación es crítica para obtener la aprobación por parte de la dirección TI. El concepto clave aquí es “sin sorpresas”.

• Reuniones diarias de seguimiento. La prueba se llevará a cabo en un lapso de 2 a 8 semanas, por lo que un retraso de uno o dos días puede poner la fecha de entrega en riesgo. Una llamada o reunión de carácter informal al final de cada día asegurará que los retrasos, riesgos y problemas sean abordados y resueltos de forma rápida, minimizando el impacto sobre el resultado final.

Fases de implementación

Una POC consiste generalmente de seis fases que pueden variar en tiempo y esfuerzo de acuerdo a la complejidad, alcance y objetivos de la solución:

Fase
Descripción
Pre-Planificación
Prerrequisitos de la prueba.
Kick-off / Formación
Instalación de software, planificación detallada de la prueba de concepto y diseño de alto nivel de la solución.
Implementación
Diseño e implementación de la solución, en conjunto con retroalimentación del usuario y capacitación en los productos comerciales.
Pruebas / Capacitación a usuario
Verificación de que los escenarios de evaluación y todos los componentes están integrados correctamente. Creación de datos para la evaluación. Los usuarios son capacitados en la solución.
Evaluación
Los usuarios y la organización TI llevan a cabo la evaluación y retroalimentación de la POC.
Conclusión
Crear una presentación de resultados, incluyendo una recomendación.
Fases de ejecución de una prueba de concepto.

La fase de pre-planificación asegura que la prueba esté configurada de forma correcta, y que las dependencias hayan sido identificadas adecuadamente para que no haya retrasos durante su ejecución. Si ésta es la primera vez que se realiza un ejercicio de esta clase, es recomendable iniciar la fase de pre-planificación con al menos un mes de anticipación al kick-off. Si ya se han realizado dos o tres pruebas de concepto, la pre-planificación puede comenzar dos semanas antes del kick-off formal.

Por otro lado, el kick-off es una combinación de inicio formal de la prueba de concepto, así como el período durante el que ésta será planeada a detalle, mientras los compromisos por parte del equipo y proveedores son acordados, para llevar a cabo los escenarios de ejecución: instalación y configuración del o los productos, revisión de requerimientos, planeación y governance, diseño detallado, revisión funcional y arquitectónica, modelo de datos y posiblemente, hitos dentro de la construcción de la POC.

La implementación incluye no sólo la codificación o configuración de la solución, sino también reuniones de seguimiento. Los stakeholders deben ser informados acerca de entregables en tiempo y forma, y qué problemas y riesgos tienen que ser abordados. Esta es también una oportunidad para dar la primera respuesta oficial al o los proveedores acerca de sus fortalezas y debilidades percibidas, dándoles la posibilidad de ajustar su desempeño. Estas reuniones también ayudarán a reducir las desconexiones y posibles fallas de comunicación dentro del equipo.

La fase de pruebas se enfoca en las pruebas funcionales básicas de la solución, que frecuentemente incluyen la capacitación de los usuarios que estarán participando en la prueba de concepto. Es importante establecer las sesiones de capacitación y evaluación antes del inicio de la ejecución, para asegurar la disponibilidad de los stakeholders.

La fase de evaluación es aquella en la que los usuarios y el departamento IT recorren la solución y aplican los criterios para su selección. Se asume que, tanto la funcionalidad de la solución así como los escenarios implementados, serán utilizados para determinar el resultado final de la solución propuesta (aceptación y adopción, o rechazo y búsqueda de nuevas opciones).

Finalmente, la conclusión incluye los entregables de la POC (requerimientos, escenarios, scorecard, evaluación), así como las recomendaciones planteadas, que pueden incluir requerimientos presupuestarios, plan de capacitación, aprovisionamiento de personal y definición y/o cambio en requerimientos para los que se implementó esta prueba. En la siguiente liga se encuentra un ejemplo de dichos entregables.

Recomendaciones adicionales

Nótese que una prueba de concepto puede también formar parte del set de herramientas del desarrollo ágil, pero bajo el entendido que su duración será de un sólo sprint o iteración (2 a 4 semanas). Cuando la solución no pueda implementarse dentro de este periodo de tiempo, primero es necesario desmenuzar el requerimiento (comúnmente denominado como “historia épica”), para posteriormente desarrollar una o varias pruebas de concepto dentro de los límites de tiempo establecidos por el sprint.

También, es importante recordar que una prueba de concepto no nos dice si lo que vamos a hacer es la mejor opción; ésta solamente nos dice si la manera en que abordamos el problema es factible: las POCs tienden a ser muy específicas y concretas; dejando fuera muchas áreas críticas que pueden requerir validación también. Por ejemplo, si estamos evaluando una herramienta de reporteo, una prueba de concepto puede estar enfocada en la generación de algún tipo particular de informe, pero su implementación puede ignorar otra funcionalidad, como la integración de la herramienta con otras aplicaciones, o qué tan personalizables son los reportes generados.

Finalmente, es necesario tomar en cuenta que el diseño de una buena prueba de concepto requeriría una comprensión completa del dominio, ya que es importante identificar por adelantado las diferentes áreas de riesgo, para que éstas sean validadas; en la mayoría de las situaciones esto es imposible, por lo que es muy probable que después de la adopción de alguna solución, el equipo (o peor aún, el cliente) descubra deficiencias en la solución adoptada. Por ello, es necesario sensibilizar al cliente sobre las limitaciones de una prueba de esta naturaleza.

Conclusiones

En el sentido más general, una POC es un prototipo que representa las capacidades o posibilidades técnicas y funcionales de un producto final. Es un modelo a escala que intenta probar que una teoría se puede transformar en una realidad, pero ni nosotros ni el cliente deberíamos esperar a tener la funcionalidad completa. Si bien una prueba de concepto puede ser útil y a veces indispensable, ésta rara vez debe ser vista como la única manera de seleccionar el producto final propuesto: ésta tiene limitaciones y sólo puede proporcionar información que debe ser considerada en combinación con otros factores; así, el propósito principal de la prueba de concepto consiste en proveer certidumbre al respecto de los aspectos básicos de rendimiento y características de un entregable.

h1

¿Qué es la estrategia TI Bimodal (Bimodal IT) y cómo podemos implementarla?

01/08/2016

Wizdoc [Icon By Buuf]  Tips & Tricks.

No importa qué tan lento vayas, siempre y cuando no te detengas.

Confucio (551 – 479 AC). Profesor, editor, político y filósofo chino.

Hace un par de semanas tuvimos una reunión con cliente relacionada a su estrategia TI y cómo piensa crecer durante el próximo año fiscal. Durante la junta salieron a relucir algunas palabras clave como innovación o implementación ágil. Sin embargo, la frase que nos dio la respuesta a lo que realmente está buscando, se resume en dos palabras: estrategia bimodal. ¿De qué se trata? ¿Por qué algunos la están considerando como la nueva panacea que asegurará la competitividad de las organizaciones TI? ¿Y cuáles son los riesgos encontrados durante su adopción?

Durante el Simposio/ITxpo llevado a cabo por la firma de consultoría e investigación de mercado Gartner en Octubre de 2014, el vicepresidente senior y jefe global de investigación, Peter Sondergaard, señaló que mientras los CIOs no sean capaces de transformar sus departamentos TI de manera que sean más ágiles y competitivos, podrán convertir sus organizaciones mediante un modelo TI Bimodal; de hecho, según Gartner, para el 2017, el 75% de las organizaciones de TI tendrá una capacidad bimodal. Este modelo se describe como “La práctica de gestionar dos modos distintos y coherentes de ejecución de TI, uno centrado en la estabilidad y el otro en la agilidad. El Modo 1 es tradicional y secuencial, haciendo hincapié en la seguridad y precisión. El Modo 2 es exploratorio y no lineal, con énfasis en la agilidad y rapidez.” Así, la organización tendrá dos maneras de llevar a cabo sus iniciativas TI:

Modo 1

• Involucra a proyectos relacionados con el mantenimiento de los sistemas centrales (core systems) – usualmente las bases de datos y sistemas legados.
• Se centra en proporcionar estabilidad y eficiencia, respetando los ciclos de desarrollo más tradicionales, como cascada.

Modo 2

• Involucra a los proyectos que ofrecen innovación y agilidad para el negocio.
• El foco está en la respuesta rápida, mientras trabaja en liberaciones frecuentes (básicamente, desarrollo ágil de software).

No tan rápido

Sin embargo, el problema que intenta atacar Gartner no es nuevo (agilidad vs. estabilidad); por el contrario, si no se lleva a cabo de manera adecuada, el modelo bimodal puede degenerar en una lucha de poder entre las dos áreas, ya que es indispensable una colaboración transparente entre ambas con el afán de agregar valor de negocio. Las consecuencias, descritas en la revista CIO Insight, se enumeran a continuación:

• La primera y de mayor impacto sería la creación de silos artificiales para productos, procesos y personas. Esta es la dirección opuesta a toda tendencia organizacional saludable de TI desde que el término “síndrome del silo funcional” fue acuñado por Phil Ensor en 1988. TI Bimodal en silos significa lanzarse al ruedo precipitadamente, ignorando numerosos estudios publicados durante los últimos cuatro decenios.

• Estancamiento del Modo 1: El enfoque bimodal propone aplicar una curita sobre la herida que representan las plataformas tradicionales, pero no hace nada por detener la hemorragia. Este modelo institucionaliza el estancamiento, al desalentar la innovación en plataformas legadas bajo el pretexto de que “si no está roto, no lo arregles”.

• Rigidez del Modo 2: En palabras de Gartner, “el Modo 2 requiere un enfoque riguroso y disciplinado”, así que el modelo bimodal prescribe un flujo de proceso definido, previsible y lógico en torno a lo que en esencia, es un proceso impredecible para la experimentación y el descubrimiento. Algo así como “Pintura por números para la obra de Jackson Pollock.”

• Sobre-simplificación de procesos: Las nuevas aplicaciones se acuñarán en torno a uno de dos modos y serán siempre encerradas en un modus operandi que sin duda resultará ser inadecuado a largo plazo. TI Bimodal cierra las puertas a las aplicaciones legadas del Modo 1 para evolucionar a las ofertas ágiles del Modo 2; por el contrario se endurecerán las condiciones para que un prototipo ágil del Modo 2 pueda convertirse en una oferta de servicio más estable de acuerdo al Modo 1.

¿Cómo implementarla?

Aunque TI Bimodal suena bastante razonable sobre el papel, en la práctica los principales retos a sortear incluyen la priorización de los proyectos, la distribución de recursos entre ambos modos, integración o intercepción de proyectos (ya que por ejemplo, una aplicación móvil no es nada sin un back-end estable que la soporte) y cómo mantener a la organización, proveedores y socios de negocios apegados a esta visión. En pocas palabras, para alcanzar la meta planteada, es fundamental definir un gobierno TI o governance adecuado. Aunque la definición completa de un gobierno TI no es el objetivo de este post, baste decir que éste debe incluir los siguientes puntos:

• La alineación entre la estrategia de la organización y las TI.

• Obtención de valor que las TI generan para la organización.

• Mecanismos que permitan mediciones apropiadas para poder valorar las TI en su conjunto y poder tomar decisiones respecto a su gobierno.

• Gestión del riesgo que en un momento dado pueda afectar e impactar negativamente en las actividades y procesos de la organización.

• Gestión de los recursos TI y la utilización óptima de los mismos.

El gobierno TI debe facilitar un modelo transparente en el que todos los interesados tengan visibilidad sobre el día a día de las operaciones y el avance del programa estratégico. Asimismo, el modelo debe proveer una comunicación y priorización claras, que ayuden en la detección y resolución de problemas más rápidamente. Por ello, el proceso de gobierno debe abordar los siguientes tres niveles de revisión:

1. Estratégico: Cuando a un nivel de dirección ejecutiva, los diferentes grupos de interés puedan mantener y hacer crecer la relación (evitando caer en luchas de poder), resolviendo asuntos importantes, manteniendo la dirección establecida y aprobando los cambios estratégicos y el plan para el futuro.

2. Táctico: Donde a través de reuniones periódicas de los grupos de interés, éstos son capaces de asegurar que se está avanzando de acuerdo a los objetivos generales del programa.

3. Operacional: Cuando todos son capaces de trabajar sobre una base del día a día para ofrecer los servicios y entregables TI, respondiendo a peticiones, problemas y consultas, en línea con los objetivos del programa.

Pic: Bimodal IT Governance Example


Para que TI Bimodal – o cualquier otra estrategia de TI – tenga éxito, la visión tiene que ser compartida por todos los niveles de la organización: la alta dirección, proveedores, socios de negocio, gerentes de proyecto y equipos de trabajo por igual. Además, el éxito se mide no sólo por la entrega de valor a la organización de TI, sino por el valor del negocio; es decir, que la estrategia TI beneficia al negocio de una manera cuantificable. El éxito del programa, por lo tanto, debe ser comunicada a todos los niveles de la organización.

Parafraseando a George Orwell, aunque los tres niveles de revisión son igualmente importantes, algunos son más iguales que otros: el nivel estratégico tiene como principal responsabilidad mantener alienada la estrategia con los objetivos de negocio, monitoreando el desempeño de las demás áreas y detectando y resolviendo cualquier riesgo de alto nivel que se llegue a presentar; por otro lado, el nivel operativo lleva a cabo los proyectos individuales, reportando su progreso y asegurándose que las métricas impuestas por los otros dos niveles se cumplan. Sin embargo, el nivel que es crucial durante la implementación es el nivel táctico (la Oficina de Gestión de Proyectos o PMO, así como el Centro de Excelencia o CoE) ya que tiene por principal responsabilidad:

• Generar estándares y procesos, así como seleccionar las herramientas y tecnologías que usará el resto de la organización.

• Revisar el rendimiento y apego a normas de desempeño acordados para todos los grupos.

• Desarrollar el programa de implementación de la estrategia.

• Llevar a cabo el presupuesto, planeación y asignación de recursos.

• Asegurarse de que todas las políticas, planes, normas, etc. permean a los equipos de la organización.

• Resolver problemas tácticos escalados con el Comité de Gobierno estratégico (Steering Committee) y

• Escalar problemas al Comité de Gobierno cuando sea apropiado (por ejemplo, asuntos contractuales).

Algunos tips durante la adopción de este modelo

La gran ventaja de Bimodal es que la organización ya debería poseer un área de operaciones/desarrollo relativamente madura trabajando en Modo 1; esta madurez es precisamente la que asegura una implementación ordenada y estable, pero impide que iniciativas “para ayer” se concreten eficazmente. Por lo tanto, el proceso de adopción debe enfocarse a la creación del Modo 2 y cómo sus equipos deben interactuar y coordinarse eficientemente con los equipos del Modo 1. Por lo tanto, una adopción debe considerar entre otros, los siguientes puntos dentro del programa de implementación de estrategia:

• Una evaluación de la capacidad (readiness assessment) para convertir un segmento de la organización al Modo 2 de operación. Esto permitirá saber qué equipos y proyectos pueden generar el mayor valor de negocio en el menor tiempo posible. Por ejemplo, los proyectos más apropiados para llevarse a cabo en el Modo 2 son aquellos que poseen 1) fechas de entrega muy agresivas, 2) un alto grado de complejidad, y 3) un alto grado de innovación.

• Identificar uno o varios coaches versados en el Modo 2 de operación – Scrum, Lean, Kanban, V-Model, etcétera – que puedan resolver las dudas durante la implementación. Éstos por supuesto, deben ir de la mano con el Centro de Excelencia para definir los procesos, herramientas y entregables de gestión y desarrollo ágil que adoptará la organización.

• En caso de que los equipos del Modo 2 se hayan integrado con el personal original de la organización, es indispensable enfocarse en el cambio cultural. Si bien las prácticas y herramientas ágiles son importantes, establecer una mentalidad ágil es indispensable. Esto implica creer firmemente en el empowerment, liderazgo subordinado o equipos multidisciplinarios. El beneficio es que aseguramos una mentalidad de colaboración y urgencia para satisfacer las cambiantes demandas del negocio.

• Para el momento en que se inicie el delivery de equipos en el Modo 2, ya se debe haber seleccionado una herramienta de planeación (por ejemplo, JIRA o VersionOne), se debe haber proporcionado el entrenamiento adecuado a los equipos y se deben haber definido las métricas mínimas para que de manera periódica, pueda existir una rendición de cuentas al Comité de Gobierno.

• Finalmente, una vez que se han dado los primeros pilotos de adopción del Modo 2 y se ha establecido la manera en que ambos tipos de equipo estarán colaborando, es indispensable generar un proceso de mejora continua para perfeccionar la integración de todos los interesados. Para este momento, iniciar la estandarización – por ejemplo, certificar los proyectos corriendo en Modo 1 en CMMi-5 y los proyectos ejecutados en Modo 2 en CMMi-3 – ya es posible.

Conclusiones

La estrategia Bimodal NO es la bala de plata. Es tan sólo un paso intermedio hacia la introducción de prácticas como DevOps. A final de cuentas, lo que cualquier organización debe buscar, es la convergencia para actualizar sus procesos e infraestructura a la realidad del mercado. Hace algún tiempo, el analista independiente Jason Bloomberg dio su propio punto de vista al respecto de lo que él llamó una “receta para el desastre” de Gartner, añadiendo su propia recomendación: … para que la transformación digital tenga éxito, debe ser de extremo a extremo – con los clientes en un extremo y los sistemas legados del otro. TI tradicional, por supuesto, sigue siendo responsable de los sistemas legados.

Así, el enfoque debe ser el de empresas exitosas como Apple, Amazon o Google:

• ¿Cómo podemos deleitar a los clientes con nuevos productos y un mejor servicio?

• ¿Cómo se puede mejorar continuamente nuestro negocio con pequeños incrementos?

• ¿Cómo podemos optimizar la cadena de valor?

• ¿Cómo nos aseguramos de que el negocio impulsa el cambio y no el departamento de TI o marketing?

La clave reside en contestar estas preguntas honestamente y trabajar en ello… o formar parte del registro fósil de empresas fallidas, junto a anti-ejemplos tales como Eastman Kodak, PanAm y Compaq.

h1

CMMI in Mexico and the world (2015)

09/22/2015

Wizdoc [Icon By Buuf]  Tips & Tricks.

Quality is the best business plan.

John Lasseter (b. 1957). American animator and film director. Chief creative officer of Pixar Animation Studios, Walt Disney Animation Studios and DisneyToon Animation Studios.

For some years now, we have been presenting the status of CMMI around the world, as this quality model is a good indicator of the overall health of the global IT industry. Previously, we explained its origin, and described its different constellations and logic behind their inclusion in this study. For clarity, we present a brief summary justifying its history and importance:

  • CMMI stands for Capability Maturity Model Integration.
  • This is a model for improvement and evaluation of processes, which focuses on certain practices of development, maintenance and operation of software systems, allowing CMMI to evaluate and measure the maturity of the software development process used by any organization.
  • CMMI measures this maturity on a scale of L1 (chaotic) to L5 (continuous improvement).
  • CMMI began its development in 1987 by the Software Engineering Institute (SEI) of Carnegie Mellon University in Pittsburgh, USA.
  • Said model was commissioned by the Government of the United States to assess its vendors, especially those allocated to contracts for defense and space research, in order to base its bids not only on cost but also on the vendor’s maturity.
  • CMMI was originally designed for the development and maintenance of software, but was later extended to systems engineering, vendor management, development and integration of products and processes, human resource management and software acquisition.
  • While CMMI proponents see it as a tool to create better quality products and increase added value, as well as customer satisfaction, in practice the importance of CMMI lies in a greater catch of larger, high-risk projects, resulting in more attractive returns.
  • Finally, CMMI is a business-oriented tool; it is not people-centered. That is to say, it will not make life easier nor result in a more productive staff; nor it will decrease production costs. It just makes sure the organization adheres to a standard and its people “know what they’re doing”.

CMMI in the world

On September 10, 2015, there were 5014 active CMMI appraisals, from levels L2 to L5, spread over 83 countries worldwide. This amounted to an increase of 8% with regard to the certificates recorded on the previous study (4031 certifications on July 2012). The list is as follows:

Country / Level L2 L3 L4 L5 Total
China 20 1843 87 128 2078
United States 267 639 12 53 971
India 14 381 2 148 545
Mexico 110 84 8 22 224
Spain 58 62 13 133
Korea, Republic Of 29 85 11 6 131
Brazil 48 52 1 7 108
Colombia 5 64 15 84
Japan 13 42 8 6 69
France 32 21 53
Thailand 9 38 3 50
Taiwan 14 23 1 38
Turkey 1 32 1 1 35
Italy 12 18 1 31
Chile 15 10 5 30
Germany 11 19 30
United Kingdom 6 18 3 27
Argentina 4 14 8 26
Portugal 13 7 5 25
Viet Nam 21 4 25
Canada 8 14 3 25
Peru 3 17 3 23
Philippines 11 6 17
Egypt 5 8 2 15
Netherlands 2 5 5 12
Malaysia 1 10 1 12
Bangladesh 11 11
Morocco 3 6 1 10
Belgium 4 6 10
Israel 2 7 9
Sri Lanka 6 1 2 9
Poland 2 6 1 9
Singapore 1 5 2 8
Hong Kong 2 4 2 8
Australia 1 6 1 8
Switzerland 3 3 1 7
Pakistan 2 5 7
Russia 3 3 6
Saudi Arabia 3 2 5
Indonesia 5 5
South Africa 4 1 5
Uruguay 1 3 4
Ecuador 2 2 4
Czech Republic 1 2 1 4
Kuwait 2 1 1 4
Hungary 1 2 3
Ukraine 1 2 3
Romania 2 1 3
Latvia 3 3
Slovakia 3 3
Lebanon 3 3
United Arab Emirates 1 2 3
Luxembourg 2 1 3
Belarus 1 1 2
Finland 2 2
Ireland 2 2
Angola 2 2
Kenya 2 2
Nigeria 2 2
Paraguay 1 1 2
Austria 1 1 2
Cyprus 1 1 2
Somalia 2 2
Venezuela 1 1
Denmark 1 1
Macedonia 1 1
Qatar 1 1
Brunei Darussalam 1 1
Kazakhstan 1 1
Bolivia 1 1
Costa Rica 1 1
Jamaica 1 1
Panama 1 1
Norway 1 1
Jordan 1 1
Tunisia 1 1
Mauritius 1 1
Mozambique 1 1
New Zealand 1 1
Guatemala 1 1
Bulgaria 1 1
Greece 1 1
Sweden 1 1
TOTAL 737 3658 134 485 5014
Table of appraisals by country, for each level of maturity. Information as of September 10, 2015.

The most significant change with respect to the previous version, is the dramatic decrease in the number of L2 appraisals (737 in 2015 vs. 872 in 2012). This is because during the last three years, organizations have matured to higher levels of CMMI, or because of the economic difficulties that are suffering Europe, China and their respective spheres of influence, many companies that had a low level of maturity are gone. The key point here is that there are not enough L2 companies being created, which in some years may lead to further consolidation of IT companies, and possibly fewer labor opportunities. Naturally, the regional outlook has been affected by this situation:

•  Anglo-America (US, Canada) has maintained a steady growth in number of certifications with just over 4% per year (996 in 2015 vs. 888 appraisals in 2012), relatively on par to its economic growth over the last three years. By contrast, in terms of L5 evaluations, their number decreased from 59 to 56 over the same period.

•  Latin America has grown enormously over the past three years, about 21% annually (511 appraisals in 2015 vs. 316 in 2012). This block is being pushed mainly by Mexico and Colombia (with 224 and 84 certifications, respectively). And regarding the L5 certifications, today Mexicans and Colombians can be proud of the level of maturity found in their organizations, because by having 22 and 15 L5 certifications respectively, both countries are becoming the main IT service providers in the region. Unfortunately, you cannot say the same for Brazil, because due to its “World Cup effect“, this South American power has stalled, growing or replacing only 7 certifications in the last three years.

•  With the economic problems being faced by southern Europe – Portugal, Spain, France, Italy and especially Greece – the whole region is going down with 379 appraisals in 2015, down from the 406 it held in 2012. Although the fall in number of certifications is more pronounced in Spain, with 20 fewer certifications than in 2012, Western Europe in general has decreased the number of its certified organizations. The exception is Eastern Europe, especially Poland (+3) and the Czech Republic (+2). Of course, the European maturity level has increased, reaching 41 L5 in these three years.

•  The Middle East has remained as a hub of IT services for years – especially Egypt and Israel – demonstrating continuity with 38 certifications, of which 10 are L5.

•  Although Africa has made an extraordinary increase (26 appraisals in 2015 vs. 8 in 2012), the continent remains underdeveloped in terms of IT industry. This is very worrying, as a continent of 1.1 billion people still does not reach the technological maturity of a country like Argentina, which has the same number of certifications, but has a population of only 42 million.

•  Australia and New Zealand have remained relatively stable (9 certifications in 2015 vs. 8 in 2012).

•  Finally, Asia (3055 certifications in 2015 vs. 2248 in 2012) has reached an annual growth of 12% being led by China and India (2078 and 545 appraisals, respectively). Both countries together have just over half of the L5 certifications in the world (276 out of 485 certifications). However, this does not detract from other countries such as Thailand (50 certifications), Turkey (35) and Vietnam (25), having made a successful effort to attract investment to the IT industry.

CMMI in Mexico: using the Fuaaa

On September 10, 2015, Mexico had 224 certifications distributed among 219 organizations, making the country the fourth in the world with more evaluations in this model, after China, India and the United States. Having overtaken Brazil, Spain, Japan and South Korea in number of certifications, Mexico is also fourth in L5 assessments (22), behind the two Asian and American giants, respectively.

If each unit is considered as independently assessed – for example, HITSS Solutions (21855) has distributed functions between the states of Queretaro and Aguascalientes, counting as two certifications – there would be a total of 251 independent evaluations, distributed among Mexican states as follows:

State / Level L2 L3 L4 L5 Total
Federal District (a.k.a. Mexico City) 16 36 3 14 69
Jalisco 38 18 3 4 63
Nuevo León 10 13 4 27
Sinaloa 22 3 25
Querétaro 4 5 6 15
Yucatán 4 2 1 7
Coahuila 4 2 6
Chihuahua 2 2 1 5
Guanajuato 2 3 5
Aguascalientes 2 2 4
México 1 3 4
Veracruz 3 1 4
Zacatecas 2 1 3
Baja California 1 2 3
Michoacán 1 1 2
Tamaulipas 1 1 2
Durango 2 2
Tlaxcala 2 2
Puebla 1 1
Tabasco 1 1
Sonora 1 1
TOTAL 118 94 8 31 251
Table of certifications by state, for each level of maturity. Information as of September 10, 2015.

• It is notorious the ongoing rivalry between Jalisco and the Federal District for supremacy in terms of CMMI adoption. While both entities had 35 and 28 certifications in 2012, three years later both have 63 and 69 certifications, respectively. Federal District organizations have focused on consolidating the L5 level, while the Mexican Silicon Valley, being more dynamic, has 38 L2 organizations: just over 32% of the country overall.

• On the third place is the northern state of Nuevo Leon, which agglomerates 27 certifications, and following very closely, the state of Sinaloa with 25. It is worth mentioning that for some time, both states also have become strong rivals seeking to offer nearshoring services to the United States, taking advantage of proximity to customers in the case of Nuevo Leon (bordering Texas upstate), or cheap labor and relative proximity to California, as is the case with Sinaloa.

• Although the state of Queretaro is still establishing itself as an important industrial and IT services hub with 15 appraisals – of which 6 are L5: second place nationally – the surprise this time is the state of Yucatan, because it had no certifications in 2012, having attained 7 in the last three years. The most significant point of its growth is that it already has a L4 certification, which will become a new L5 in less than a year.

Conclusions

It’s interesting to see how the North-South divide does not apply to IT: so distant nations that are hardly heard in the news – such as Thailand and the Philippines – are powers within this industry. Of course, although it is not reflected in this study, there are multinationals that are responsible for these success stories: for example, the renowned Irish consulting company Accenture owns seventeen L3 certifications, one L4 and nine L5, distributed throughout Europe, Asia and Latin America – 27 in total, equal in number to those of the entire United Kingdom.

On the other hand, it is sad to see how powers in this area (Brazil, Spain) are deflating due to economic problems, as this will impact the medium and long term viability of their IT industries. This in fact is already evident in the case of Spain, since in recent years, Mexico has seen a new wave of Spanish immigrants fleeing the current economic crisis, and whom for better or worse, have benefited Mexico at the expense of Spain.

Speaking of Mexico, it is a pleasant surprise to see how the country has risen to the fourth place in the world rankings. Perhaps due to greater economic integration we have with the United States, or possibly some of the programs implemented by the federal government are paying off. Leaving aside the cause for another time, the reality is that by having an IT market worth approximately 23.63 billion dollars and an expected growth of 6.4% for 2015, Mexico is becoming one of the major global players. According to Gartner:

  • On 2016, one in five of the leading providers of local IT services will be acquired by a multinational.
  • By 2017, the dynamic server market in Mexico will experience the highest growth in the region.
  • On 2018, Mexico will become a Latin American power in data center services, which will result in large-scale creation of several dozen data centers.
  • By 2018, retailers in Mexico will double their existing investments in CRM, ERP, supply chain and BI due to the rapid growth of the retail market.

However, we must not lower our guard: with an economic downturn in our doorsteps, many of these plans can come down. For now, let’s have a toast: this is an occasion to celebrate.

h1

CMMI en México y el mundo (2015)

09/15/2015

Wizdoc [Icon By Buuf]  Tips & Tricks.

La calidad es el mejor plan de negocios.

John Lasseter (n. 1957). Animador y director de cine estadounidense. Director creativo de los Pixar Animation Studios, Walt Disney Animation Studios y DisneyToon Animation Studios.

Desde hace unos años, hemos venido presentando el estatus de CMMI alrededor del mundo, debido a que este modelo de calidad es un buen indicador de la salud general de la industria IT a nivel global. Anteriormente, explicamos su origen, y describimos sus diferentes constelaciones y lógica usada para incluirlas en este estudio. Para efectos de claridad, a continuación presentamos un pequeño resumen justificando su historia e importancia:

  • CMMI significa Capability Maturity Model Integration (Español: Integración de Modelos de Madurez de Capacidades).
  • Éste es un modelo de mejora y evaluación de procesos, que está centrado en ciertas prácticas del desarrollo, mantenimiento y operación de sistemas de software, por lo que CMMI permite evaluar y medir la madurez del proceso de desarrollo de software en una organización.
  • CMMI mide esta madurez en una escala de L1 (caótico) a L5 (mejora continua).
  • CMMI inició su desarrollo en 1987 por el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon en Pittsburgh, Estados Unidos.
  • Dicho modelo fue encargado por el gobierno de los Estados Unidos para evaluar a sus proveedores, especialmente aquellos asignados a contratos para la defensa e investigación espacial, con la finalidad de basar sus licitaciones no sólo en costo, sino también en la madurez del proveedor.
  • CMMI fue concebido inicialmente para el desarrollo y mantenimiento de software, pero más tarde fue extendido a la ingeniería de sistemas, gestión de proveedores, desarrollo e integración de productos y procesos, gestión de recursos humanos y adquisición de software.
  • Si bien los proponentes de CMMI lo consideran como una herramienta para crear productos de mayor calidad, así como incrementar el valor agregado y satisfacción al cliente, en la práctica la importancia de CMMI radica en una mayor captación de proyectos más grandes y de alto riesgo, que equivalen a rendimientos más atractivos.
  • Por último, CMMI es una herramienta orientada a la empresa; no a las personas. Es decir, no hará la vida del personal más fácil o productiva; tampoco disminuirá costos de producción. Sólo permite asegurarse que la organización se adhiere a un estándar y su gente “sabe lo que está haciendo”.

CMMI en el mundo

Al 10 de Septiembre de 2015, existían 5014 certificaciones CMMI activas, desde el nivel L2 hasta el L5, repartidas entre 83 países alrededor del mundo. Esto significó un incremento del 8% anual con respecto a las certificaciones contabilizadas en el estudio previo (4031 certificaciones en Julio de 2012). La lista es la siguiente:

País / Nivel L2 L3 L4 L5 Total
China 20 1843 87 128 2078
United States 267 639 12 53 971
India 14 381 2 148 545
Mexico 110 84 8 22 224
Spain 58 62 13 133
Korea, Republic Of 29 85 11 6 131
Brazil 48 52 1 7 108
Colombia 5 64 15 84
Japan 13 42 8 6 69
France 32 21 53
Thailand 9 38 3 50
Taiwan 14 23 1 38
Turkey 1 32 1 1 35
Italy 12 18 1 31
Chile 15 10 5 30
Germany 11 19 30
United Kingdom 6 18 3 27
Argentina 4 14 8 26
Portugal 13 7 5 25
Viet Nam 21 4 25
Canada 8 14 3 25
Peru 3 17 3 23
Philippines 11 6 17
Egypt 5 8 2 15
Netherlands 2 5 5 12
Malaysia 1 10 1 12
Bangladesh 11 11
Morocco 3 6 1 10
Belgium 4 6 10
Israel 2 7 9
Sri Lanka 6 1 2 9
Poland 2 6 1 9
Singapore 1 5 2 8
Hong Kong 2 4 2 8
Australia 1 6 1 8
Switzerland 3 3 1 7
Pakistan 2 5 7
Russia 3 3 6
Saudi Arabia 3 2 5
Indonesia 5 5
South Africa 4 1 5
Uruguay 1 3 4
Ecuador 2 2 4
Czech Republic 1 2 1 4
Kuwait 2 1 1 4
Hungary 1 2 3
Ukraine 1 2 3
Romania 2 1 3
Latvia 3 3
Slovakia 3 3
Lebanon 3 3
United Arab Emirates 1 2 3
Luxembourg 2 1 3
Belarus 1 1 2
Finland 2 2
Ireland 2 2
Angola 2 2
Kenya 2 2
Nigeria 2 2
Paraguay 1 1 2
Austria 1 1 2
Cyprus 1 1 2
Somalia 2 2
Venezuela 1 1
Denmark 1 1
Macedonia 1 1
Qatar 1 1
Brunei Darussalam 1 1
Kazakhstan 1 1
Bolivia 1 1
Costa Rica 1 1
Jamaica 1 1
Panama 1 1
Norway 1 1
Jordan 1 1
Tunisia 1 1
Mauritius 1 1
Mozambique 1 1
New Zealand 1 1
Guatemala 1 1
Bulgaria 1 1
Greece 1 1
Sweden 1 1
TOTAL 737 3658 134 485 5014
Tabla de certificaciones por país, para cada nivel de madurez. Información actualizada al 10 de Septiembre de 2015.

El cambio más significativo con respecto a la versión anterior, es la dramática disminución en el número de certificaciones L2 (737 certificaciones en 2015 vs. 872 en 2012). Esto se debe a que durante estos últimos tres años, las organizaciones han madurado hacia los niveles superiores de CMMI, o que debido a las dificultades económicas que están sufriendo Europa, China y sus respectivas esferas de influencia, muchas empresas que tenían un nivel bajo de madurez han desaparecido. El punto clave aquí es que no se están creando suficientes empresas L2, lo que en algunos años puede desembocar en mayor consolidación de empresas de TI, y posiblemente, menores oportunidades laborales. Naturalmente, el panorama regional se ha visto afectado por esta situación:

•  Anglo-América (Estados Unidos, Canadá) ha mantenido un crecimiento sostenido en número de certificaciones con poco más del 4% anual (996 certificaciones en 2015 vs. 888 en 2012), relativamente a la par de su crecimiento económico durante estos últimos tres años. Por el contrario, en términos de certificaciones L5, su número ha disminuido de 59 a 56 a lo largo de este periodo de tiempo.

•  América Latina ha crecido enormemente durante estos tres años, en alrededor del 21% anualmente (511 certificaciones en 2015 vs. 316 en 2012). Este bloque está siendo empujado principalmente por México y Colombia (224 y 84 certificaciones, respectivamente). Y en cuanto a las certificaciones L5, hoy por hoy, los mexicanos y colombianos pueden sentirse orgullosos del nivel de madurez encontrado en sus organizaciones, porque al contar con 22 y 15 certificaciones L5, ambos países se están convirtiendo en los principales proveedores de servicios TI de la región. Lamentablemente, no se puede decir lo mismo de Brasil, pues debido a su “Efecto Mundial de Fútbol“, la potencia sudamericana se ha estancado, creciendo o reemplazando tan sólo 7 certificaciones en los últimos tres años.

•  Con los problemas económicos que está enfrentando Europa Meridional – Portugal, España, Francia, Italia y sobre todo, Grecia – la región en su conjunto va a la baja con 379 certificaciones en 2015, disminuyendo de las 406 que poseía en 2012. Aunque la caída en número de certificaciones es más pronunciada en España, con 20 certificaciones menos que en 2012, en términos generales toda Europa Occidental ha disminuido en número de organizaciones certificadas. La excepción es Europa Oriental, especialmente Polonia (+3) y la República Checa (+2). Claro que, el nivel de madurez Europeo se ha visto incrementado, llegando a 41 L5 en estos tres años.

•  El Medio Oriente ha permanecido como un centro de servicios TI por años – especialmente Egipto e Israel – demostrando continuidad con 38 certificaciones, de las cuales 10 son L5.

•  Aunque África ha realizado un incremento extraordinario (26 certificaciones en 2015 vs. 8 en 2012), éste continente sigue estando poco desarrollado en términos de industria TI. Esto es muy preocupante, ya que un continente de 1100 millones de personas no alcanza la madurez tecnológica de un país como Argentina, que posee el mismo número de certificaciones, pero cuenta con una población de apenas 42 millones de habitantes.

•  Australia y Nueva Zelanda se han mantenido relativamente estables (9 certificaciones en 2015 vs. 8 en 2012).

•  Finalmente, Asia (3055 certificaciones en 2015 vs. 2248 en 2012) ha alcanzado un crecimiento del 12% anual con China y la India a la cabeza (2078 y 545 certificaciones, respectivamente). Ambos países en su conjunto poseen poco más de la mitad de las certificaciones L5 en el mundo (276 certificaciones de 485). Sin embargo, esto no le resta a otros países como Tailandia (50 certificaciones), Turquía (35) y Vietnam (25), quienes han hecho un esfuerzo exitoso por atraer inversión a la industria TI.

CMMI en México: usando el Fuaaa

Al 10 de Septiembre de 2015, México contaba con 224 certificaciones distribuidas entre 219 organizaciones, convirtiendo al país en el cuarto en el mundo con mayor número de evaluaciones en este modelo, después de China, India y los Estados Unidos. Habiendo superado a Brasil, España, Japón y Corea del Sur en número de certificaciones, también México queda en cuarto lugar en evaluaciones L5 (22), detrás de los dos gigantes asiáticos y el norteamericano, respectivamente.

Si se considera cada unidad evaluada de manera independiente – por ejemplo, HITSS Solutions (21855) tiene funciones distribuidas entre los estados de Querétaro y Aguascalientes, contando como dos certificaciones – existirían un total de 251 evaluaciones independientes, distribuidas entre los estados mexicanos de la siguiente manera:

Estado / Nivel L2 L3 L4 L5 Total
Distrito Federal 16 36 3 14 69
Jalisco 38 18 3 4 63
Nuevo León 10 13 4 27
Sinaloa 22 3 25
Querétaro 4 5 6 15
Yucatán 4 2 1 7
Coahuila 4 2 6
Chihuahua 2 2 1 5
Guanajuato 2 3 5
Aguascalientes 2 2 4
México 1 3 4
Veracruz 3 1 4
Zacatecas 2 1 3
Baja California 1 2 3
Michoacán 1 1 2
Tamaulipas 1 1 2
Durango 2 2
Tlaxcala 2 2
Puebla 1 1
Tabasco 1 1
Sonora 1 1
TOTAL 118 94 8 31 251
Tabla de certificaciones por estado, para cada nivel de madurez. Información actualizada al 10 de Septiembre de 2015.

• Es notoria la continua rivalidad entre Jalisco y el Distrito Federal por la supremacía en cuanto a la adopción de CMMI. Mientras en 2012 ambas entidades federativas tenían 35 y 28 certificaciones, tres años más tarde ambas cuentan con 63 y 69 certificaciones respectivamente. Las organizaciones del Distrito Federal se han enfocado en la consolidación del nivel L5, mientras el Silicon Valley Mexicano, siendo mucho más dinámico, tiene 38 organizaciones con L2: poco más del 32% total del país.

• En tercer lugar tenemos al norteño estado de Nuevo León, que aglomera 27 certificaciones, y pisándole los talones, el estado de Sinaloa con 25. Vale la pena mencionar que desde hace algún tiempo, ambos estados también se han convertido en fuertes rivales buscando ofrecer servicios de nearshoring hacia los Estados Unidos, aprovechando la cercanía con los clientes en el caso de Nuevo León (limitando con Texas al norte del estado), o la mano de obra barata y relativa cercanía con California, como es el caso de Sinaloa.

• Aunque el estado de Querétaro sigue estableciéndose como un importante centro industrial y de servicios TI con 15 certificaciones – de las cuales 6 son L5: el segundo lugar a nivel nacional – la sorpresa en esta ocasión es el estado de Yucatán, pues sin tener una sola certificación en 2012, ha alcanzado 7 en los últimos tres años. Lo más significativo de su crecimiento es que posee una certificación L4, la cual se convertirá en una nueva L5 en menos de un año.

Conclusiones

Es interesante ver cómo la brecha Norte-Sur no aplica en TI: naciones tan distantes y de las que casi no escuchamos en las noticias – como Tailandia o las Filipinas – son potencias en esta industria. Claro que, aunque no se ve reflejado en este estudio, hay multinacionales que son las responsables de estas historias de éxito: por ejemplo, la reconocida empresa de consultoría irlandesa Accenture es dueña de diecisiete certificaciones L3, una L4 y nueve L5 repartidas entre Europa, Asia y América Latina – 27 en total, equivalentes en número a las de todo el Reino Unido.

Por otro lado, es triste ver cómo potencias en este rubro (Brasil, España) se están desinflando debido a problemas económicos, pues esto impactará a mediano y largo plazo en la viabilidad de sus industrias TI. Esto de hecho, ya es notorio en el caso de España, pues en los últimos años, México ha visto una nueva oleada de inmigrantes españoles que huyen de la crisis económica y que para bien o para mal, han beneficiado a México, a costa de España.

Y hablando de México, es una grata sorpresa ver cómo el país ha subido al cuarto lugar en el ranking mundial. Tal vez se deba a la mayor integración económica que tenemos con los Estados Unidos, o posiblemente algunos de los programas implementados por el gobierno federal están dando resultados. Dejando de lado la causa para otro momento, la realidad es que con un mercado TI de aproximadamente 23,634 millones de dólares y un crecimiento esperado para 2015 del 6.4%, Mexico se está posicionando como uno de los grandes jugadores globales. De acuerdo a Gartner:

  • En el 2016, uno de cada cinco de los principales proveedores de servicios TI locales serán adquiridos por una multinacional.
  • Para el 2017, el mercado de servidores dinámicos en México experimentará el mayor crecimiento en la región.
  • En el 2018, México se convertirá en una potencia a nivel Latinoamérica en materia de servicios de centros de datos, lo que dará como resultado la creación a gran escala de varias decenas de centros de datos.
  • Para el 2018, los minoristas en México duplicarán sus inversiones actuales en CRM, ERP, gestión en la cadena de suministro y en BI, debido al rápido crecimiento del mercado minorista.

Sin embargo, no hay que bajar la guardia: con una desaceleración económica en puerta, muchos de estos planes se pueden venir abajo. Por lo pronto, brindemos: ésta es una ocasión para celebrar.

h1

50 años de la Ley de Moore

04/24/2015

Wizdoc [Icon By Buuf]  Reflexiones.

Para el 2020, la mayoría de las computadoras personales poseerán la potencia de cálculo de un cerebro humano. Esto no quiere decir que sean cerebros; sólo significa que en términos de procesamiento en bruto, éstos pueden procesar los bits tan rápido como un cerebro humano. Entonces la interrogante sería, ¿qué tan lejano se encuentra el desarrollo de una máquina tan inteligente como nosotros?

Seth Shostak (n. 1943), físico y astrónomo estadounidense, Astrónomo Senior del Instituto SETI (organización dedicada a la búsqueda de vida extraterrestre).

El 19 de abril de 1965, el ingeniero químico y cofundador de Intel, Gordon Moore, publicó en la revista especializada Electronics un artículo de apenas cuatro cuartillas, denominado “Atiborrando más componentes en circuitos integrados” (Título original en inglés: Cramming more components onto integrated circuits). En éste, mediante algunas gráficas, una tira cómica y algunas reflexiones, el autor definió la que ahora conocemos como la Ley de Moore, que predica: aproximadamente cada dos años se duplica el número de transistores en un circuito integrado. Lo interesante de dicha “ley” – que más bien es una observación empírica, pero por el bien del argumento, dejémoslo así – es que ésta fue enunciada cuando la manufactura de los microprocesadores todavía estaba en pañales, y casi diez años antes de que surgieran las primeras computadoras personales.

A cincuenta años de su publicación, algunas estimaciones atribuyen a la Ley de Moore hasta un 40 por ciento del crecimiento en la productividad mundial durante las últimas dos décadas, debido principalmente a la explosión de las tecnologías de la información y las telecomunicaciones; ambas hechas posibles gracias a las mejoras en el desempeño de los semiconductores y por supuesto, una disminución en los costos del hardware por hasta 35 por ciento año con año.

Es así como este pequeño artículo ha definido a la industria de los microprocesadores por casi medio siglo, pues desde la década de los 1970 todos los proveedores de semiconductores – Intel, ATI Technologies, Samsung, AMD – se han impuesto esta meta como parte de su objetivo de negocios: comenzando en 1974 con el humilde procesador Intel 8088, el cual poseía 29,000 transistores mediante un proceso de tres micrómetros (tres milésimas de milímetro por transistor) y alcanzando una velocidad de 4.77 MHz, ahora contamos con el Intel Broadwell, liberado a finales de 2014 y el cual posee 1,900 millones de transistores mediante un proceso de 14 nanómetros (catorce millonésimas de milímetro por transistor), operando a una velocidad de 3.1 GHz y consumiendo apenas 28 watts.

Si la Ley de Moore se conserva, para el 2020 existirán procesadores con una densidad de 15,000 millones de transistores en un proceso de tan sólo 5 nanómetros; a mediados del 2026, finalmente llegaremos al límite teórico impuesto por las leyes de la física: un transistor tendrá la misma longitud de un átomo, por lo que para continuar con la tendencia, se tendrá que echar mano de otros procesos derivados de la nanotecnología, así como materiales basados en el carbono como el grafeno, resultando en la obsolescencia de los semiconductores basados en el silicio. Por ejemplo, desde hace un par de años IBM ha estado llevando a cabo experimentos con nanotubos de carbono, “mejorando la eficiencia energética por más de un orden de magnitud”:

Pic: Carbon nanotube transistors (CNT) arranged as a neuron circuit. Close up of CNT.

Los nanotubos de carbono de pared simple (Single-Walled Carbon Nanotube – SWNT) han atraído la atención de los científicos hacia diversas aplicaciones, incluyendo transistores de efecto de campo (FET), memoria no volátil, circuitos lógicos, biosensores y sinapsis biomiméticas debido a su tamaño nanoescalar y propiedades electrónicas. (Fuente de imagen y pie de página: iopscience.iop.org)

Es precisamente aquí donde radica la relevancia de la Ley de Moore: no importa cuántas veces han dicho que está a punto de finalizar, siempre existirá alguna nueva tecnología o descubrimiento científico que puede darle continuidad. Y esto ha permitido alcanzar algunos de los avances tecnológicos más importantes de esta generación, incluyendo la computadora personal, el surgimiento de la Internet, los videojuegos y la tecnología móvil, así como otras “leyes” igualmente fantásticas, como la densidad de memoria, capacidad de red, transmisión de datos u operaciones por joule de energía disipada.

Sin embargo, si bien tecnológicamente hablando esta tendencia puede seguir su curso por algunos años o décadas más, existe también la posibilidad de que los costes se disparen debido al salto tecnológico que implican mayores densidades de procesamiento: el principal reto al que se enfrentan los fabricantes de semiconductores hoy en día consiste en mantener costos bajos y un margen aceptable. Empero, incluso si la Ley de Moore se detiene por completo, es muy probable que los procesadores se conviertan en commodities, dejando a otros elementos como el sistema operativo o las aplicaciones como los mayores diferenciadores. Aunque esto definitivamente golpearía a la industria, ésta no sería aniquilada, pues así como los precios de los microprocesadores tenderían a la baja, los costos de investigación y desarrollo tenderían a bajar igualmente. La solución sería convertirse en fabless, consolidarse o integrarse verticalmente con otros proveedores.

¿Qué veremos en los próximos años? pronto tendremos más wearables como el Apple Watch; dispositivos de realidad aumentada y realidad virtual como Google Glass y Oculus Rift; tablets hechas exclusivamente para el funcionamiento de videojuegos como el Razer Edge; la próxima generación de dispositivos de impresión 3D, computadoras al alcance de todos y un sinfín de dispositivos y sus aplicaciones que hasta hace poco, nos habrían parecido como ideas salidas de la ciencia ficción. Incluso si nunca llegamos al ascenso a la trascendencia, es muy probable que la Ley de Moore y sus beneficios se sigan dando – y puedan ser disfrutados – durante muchos años más. Indudablemente, lo mejor está por venir.

h1

Automatización de pruebas: una introducción

12/19/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

“f u cn rd ths, u cn gt a gd jb n sftwr tstng.”

El año se está terminando, y en México el puente Guadalupe-Reyes prácticamente significa el cierre de este 2014. Sin embargo, en vez de decir “estamos hechos; nos vemos en 2015”, todavía salen detalles aquí y allá en el trabajo que nos impiden relajarnos completamente: somos víctimas de una importante rotación de personal así como fechas de liberación, seguidas de un freeze. Aunque algunos recursos dejen la empresa, ciertos entregables deben estar terminados durante el transcurso de las próximas dos semanas.

Nuestro Coco es el proceso de pruebas, que para algunos proyectos debe llevarse a cabo de forma enteramente manual, lo que ha resultado en una ardua labor por parte de los testers y hasta de los mismos desarrolladores. Sin embargo, de momento no hay mucho que podamos hacer para cambiar esta situación, pues el ambiente sobre el que estamos trabajando es enteramente del cliente, y ya que aquél cerró su ciclo fiscal hace poco menos de un mes, ya no dispone del presupuesto necesario para adquirir una suite de pruebas automatizadas que permitan aligerar la carga de trabajo, al menos en lo que resta del año.

Aplicando un poco de pensamiento crítico, ¿acaso las pruebas automatizadas son tan buenas como dicen? ¿No será más práctico emplear a un ejército de testers que adquirir una herramienta? ¡Yo tenía la idea de que con JUnit y TDD es más que suficiente! ¿Qué consideraciones deberemos tomar si nos decidimos por el camino de la automatización? Es así como presento una pequeña introducción a la automatización de pruebas y algunos consejos para no dejarnos engañar por herramientas que se autodescriben como el non plus ultra, apoyando a tomar una decisión racional con respecto a una actividad que de forma ideal debería tomar el 20-25% del tiempo total necesario para generar un entregable técnico.

Algunas ideas erróneas sobre el automated testing

Primero que nada, es necesario aclarar ciertas falacias que han plagado la industria por años, gracias a elaborados trucos de marketing. En el excelente artículo Test Automation Snake Oil (con un título equivalente a “El fraude de la automatización de pruebas”) el autor e ingeniero de software James Bach describe algunos “supuestos peligrosos” que nos pueden llevar al desastre:

  • Las pruebas consisten en una secuencia de acciones. Una manera más útil de pensar en las pruebas es como una secuencia de interacciones entremezclada con evaluaciones; algunas son predecibles y objetivas, mientras otras son complejas, ambiguas y volátiles.
  • Una prueba significa repetir las mismas acciones una y otra vez. La variabilidad es una de las grandes ventajas de las pruebas manuales.
  • Podemos automatizar acciones de prueba. Probablemente la parte más difícil de la automatización es interpretar los resultados de la prueba, separando anomalías inofensivas de problemas graves. Un ejemplo clásico es el error de división del Intel Pentium.
  • Una prueba automatizada es más rápida ya que no necesita ninguna intervención humana. Todas las suites de pruebas automatizadas requieren de intervención humana, aunque sólo sea para diagnosticar los resultados y corregir pruebas erróneas.
  • La automatización reduce el error humano. Sí, se reducen algunos errores. Aquellos que los seres humanos hacen cuando se les pide llevar a cabo una larga lista de actividades mentales y táctiles aburridas. Pero otros errores se amplifican.
  • Podemos cuantificar los costos y beneficios de las pruebas automatizadas vs. manuales. La realidad es que las pruebas manuales y las pruebas automatizadas son dos procesos diferentes, en lugar de dos maneras diferentes para ejecutar el mismo proceso.
  • La automatización conducirá a un “importante ahorro en costos laborales”. Los costos de desarrollo de la automatización, de operación de las pruebas automatizadas, del mantenimiento de la automatización conforme el producto cambia y de cualquier otra tarea que es requerida por la automatización, deben sopesarse contra los costos de diseño, configuración e implementación de pruebas manuales. Usualmente la automatización resulta ser más costosa.
  • La automatización no dañará el proyecto de prueba. Ciertamente, es peligroso automatizar algo que no entendemos. Si no tenemos una clara estrategia de pruebas antes de la introducción de la automatización, el resultado será una gran masa de código de prueba que nadie entiende completamente.

Siendo así las cosas, la automatización se define como una técnica que facilita las labores repetitivas, liberando a los testers de actividades tediosas para permitirles concentrarse en lo que verdaderamente importa: la funcionalidad de negocio que el usuario espera.

Automatizando

Los testers son percibidos con frecuencia como los cuellos de botella durante la entrega de productos de software. Así, se les exige probar más y más código en cada vez menos tiempo. Por otro lado, conforme diferentes versiones de un código son liberadas, la nueva funcionalidad debe probarse en conjunto con las características previamente existentes, por lo que el ciclo de pruebas tiende a volverse cada vez más lento. Hoy por hoy, ya existen herramientas que permiten reducir los tiempos de prueba mediante una interfaz gráfica de usuario, mientras otras herramientas facilitan la ejecución de pruebas de desempeño – que anteriormente tenían que implementarse mediante un ejército de testers simulando los usuarios de una aplicación.

En un intento de hacer más con menos, no hay más remedio que usar estas herramientas en los proyectos. La automatización de pruebas consiste en el uso de herramientas de software especializadas que permiten controlar la ejecución de pruebas, comparación de resultados reales contra resultados previstos, creación de las condiciones previas para la ejecución de pruebas, así como otras funciones de control y presentación de reportes. Comúnmente, la automatización de pruebas busca automatizar procesos manuales y repetitivos ya existentes que siguen una metodología de pruebas formal. La mayoría de las herramientas de prueba pueden ayudar a automatizar tareas como la instalación del producto, creación de datos de prueba e interacción con la interfaz de usuario; el objetivo principal consiste en simplificar las pruebas de regresión: es decir, se genera un repositorio de casos de prueba detallados que son repetibles y que se ejecutan en su conjunto cada vez que haya un cambio en la aplicación. Esto se hace para asegurar que ningún cambio traiga consecuencias imprevistas. Es importante recalcar que la automatización de pruebas es algo caro y debe considerársele como un complemento – no un reemplazo – de las pruebas manuales. Sólo a largo plazo o en productos de software con ciclos de mantenimiento muy extensos puede llegar a ser más rentable que trabajar con grupos de testers dedicados.

Pros y Contras

No todo es miel sobre hojuelas, sin embargo. Previo a adoptar una herramienta de automatización de pruebas es necesario tomar en consideración que el verdadero costo de la automatización se mide por el número de pruebas manuales que no estamos ejecutando y por lo tanto, el número de incidencias o bugs que estamos dejando pasar. Eventualmente, la decisión entre automatizar o seguir procesos manuales deberá llevarse a cabo contestando las siguientes preguntas: ¿Si automatizo esta prueba, qué pruebas manuales puedo perder? ¿Cuántos errores de usuario pueden escaparse al no ejecutar dichas pruebas? ¿Cuál será su severidad? De acuerdo al ingeniero de pruebas y autor Brian Marick:

Una prueba está diseñada para un propósito determinado: revisar si algunos aspectos de una o más características funcionan. Cuando una prueba automatizada detecta incidencias, deberías asumir que encontrarás errores que parecen no tener nada que ver con el propósito original de la prueba. Gran parte del valor de una prueba automatizada radica en lo bien que se puede hacer eso.

Marick, Brian. (1998). “When Should a Test Be Automated?” uml.org.cn.

En caso de decidirse por la automatización, deben incluirse medidas para investigar si la incorporación de dicha herramienta será beneficiosa para el proyecto, teniendo en cuenta los requisitos de prueba, ambiente de pruebas disponible, personal capacitado, entorno de usuario, plataforma del proyecto, así como las características de la aplicación a ser validada. También es importante realizar las estimaciones y modificación correspondiente al plan de proyecto para garantizar el tiempo mínimo indispensable para la instalación de la herramienta, así como la jerarquía de requerimientos; es necesario realizar pruebas de concepto (Proof of Concept – PoC) con las potenciales herramientas y utilerías de prueba, validando la compatibilidad con el ambiente aplicativo y buscando soluciones alternativas a problemas de incompatibilidad que surjan durante esta PoC. En términos generales, algunos de los pros y contras de adoptar herramientas de automatización de pruebas serían los siguientes:

Pros:

  • Si es necesario ejecutar una serie de pruebas en múltiples ocasiones, para un gran número de usuarios.
  • Código que cambia con frecuencia, buscando detectar regresiones en el momento oportuno.
  • Ejecutar pruebas durante los escenarios principales para detectar regresiones de forma periódica. Por ejemplo: en un build nocturno o nightly build.
  • Matriz de pruebas de grandes dimensiones, como un producto destinado a diferentes idiomas en plataformas y sistemas operativos diversos.
  • Ejecución en paralelo sobre diferentes máquinas – mientras que las pruebas manuales tendrían que ejecutarse secuencialmente.

Contras:

  • La automatización es demasiado costosa (tiempo y/o presupuesto). Escribir los casos de prueba y configurar la herramienta siempre es más costoso al principio que correr las pruebas de forma manual.
  • No se pueden automatizar referencias visuales. Por ejemplo, si la herramienta no permite detectar el tipo de letra o color, será necesaria una prueba manual.
  • No se pueden automatizar pruebas al azar, por lo que es imposible detectar verdaderos errores de usuario.
  • Ambientes complejos donde una herramienta no sea suficiente para probar la aplicación en su conjunto. Por ejemplo, aplicaciones multiplataforma.

Conclusiones

La automatización puede ofrecer grandes beneficios, siempre y cuando recordemos que “testing” no sólo significa probar lo mismo una y otra vez hasta el cansancio: éste implica evaluar los resultados de acuerdo a diferentes entradas y concentrarse en aquellas incidencias que restan valor agregado al cliente. Luego, tenemos que ser muy cuidadosos con el tipo de herramienta que utilizaremos, pues ninguna de las herramientas encontradas en el mercado actual hará el trabajo por nosotros. Finalmente, es importante tener una clara idea de qué tareas puede simplificar y la utilicemos como un complemento de las pruebas manuales, ya que:

Un tonto con una herramienta sigue siendo un tonto.

Grady Booch (n. 1955), ingeniero de software estadounidense, co-autor del Lenguaje Unificado de Modelado (UML).