SG #58

Estudio de Salarios SG 2019

pedrogk — Wed, 06 Feb 2019 23:05:08 +0000

Estudio de Salarios SG 2019

pedrogk Wed, 02/06/2019 - 17:05

Publicado en

SG #58

Autor

Pedro Galván

Te presentamos los resultados de la undécima edición del Estudio de Salarios SG.

Agradecimientos

Antes de continuar, agradecemos a la empresa iTexico, que a través de su patrocinio hizo posible el presente estudio. De acuerdo con Guillermo Ortega, cofundador y director de operaciones de iTexico, “el estudio de salarios de Software Guru muestra la competitividad de iTexico en el mercado laboral, no sólo por los niveles de salario y prestaciones que ofrecemos sino también por el papel principal que juega la diversidad y la equidad en nuestro equipo humano.”

Adicionalmente agradecemos el apoyo de los siguientes organismos que participaron en la difusión de la encuesta: AMITI, CANIETI, CSOFTMTY y PROSOFTWARE.

Fuente de los datos y contexto

Las cifras y estadísticas mostradas en este reportaje se generaron con base en los datos obtenidos durante una encuesta realizada en noviembre de 2018 por medio de una encuesta abierta en internet. Después de limpiar los datos, quedamos con 2,215 respuestas válidas, de las cuales 2,075 son de personas que indicaron residir en México. Por default, las estadísticas mostradas en este reporte se basan en este subconjunto de 2,075 datos.

Todos los datos se refieren a salario bruto mensual, expresado en pesos mexicanos. En la mayoría de las tablas mostramos los siguientes datos: mediana, media (promedio), desviación estándar y tamaño de la muestra. Toma esto en cuenta para las conclusiones que generes.

Salario medio

De acuerdo a los datos recopilados este año, el salario medio de un profesionista de software en México es de $33,000 pesos brutos mensuales. Ese dato se refiere a la mediana, que consideramos que es el valor que tiene más sentido en este tipo de casos.

Tabla 1. Estadísticas descriptivas del salario en México

La tabla 1 muestra el resumen de estadísticas descriptivas para el salario. Como podemos ver, el 50% de los profesionistas de software en México tienen un sueldo bruto mensual entre 20 mil y 50 mil pesos al mes. La desviación estándar (más de 26 mil pesos) es alta, lo cual es de esperarse ya que este es un primer acercamiento sin tomar en cuenta variables que nos puedan ayudar a aumentar la precisión, tales como experiencia, habilidades y ubicación geográfica; haremos esto más adelante.

Respecto al año anterior, el salario medio creció apenas de 32 a 33 mil pesos, es decir un 3.1%, y el primer quartil se mantuvo en la misma cifra (20 mil pesos). Así que en términos reales (al considerar la inflación), el salario promedio de nuestra profesión bajó en este año. ¿Cómo puede ser eso, si hay tanta demanda? Bueno, al analizar los números con mayor profundidad, notamos que tenemos una proporción mayor que hace un año de personas con menos de 5 años de experiencia. Al parecer, lo que está sucediendo es que ante la gran demanda de talento, estamos teniendo una mayor proporción de desarrolladores “novatos” que por lo tanto están en los escalafones de compensación más bajos.

Figura 1. Histograma de frecuencias, salario mensual bruto (miles de pesos)

La figura 1 muestra un histograma de frecuencia de los salarios, con una curva de densidad. Como podemos ver, la curva tiene dos jorobas, destacando un grupo con salario medio de 20 mil pesos y otro con salario medio de alrededor de 36 mil pesos. Como veremos más adelante, la pertenencia a alguno de estos grupos depende principalmente de la experiencia y nivel de inglés.

Actividades y roles

La tabla 2 muestra algunos de los principales roles a los que se dedican los profesionistas de software, y los salarios asociados a cada uno. Los participantes en la encuesta podían elegir hasta 3 roles que realizan, es por ello que la suma de los porcentajes es mayor a 100%.

Como de costumbre, los roles de preventa, venta y dirección perciben los salarios más altos, seguidos por los roles de consultoría y arquitectura. Hace un año ya habíamos notado que el rol de sysadmin estaba aumentando su valor, posiblemente como consecuencia del movimiento DevOps y el énfasis en Site Reliability Engineering, y esto ha continuado, posicionando a un sysadmin con un salario mayor que el de un project manager, lo cual hubiera sido inaudito hace unos años. Otro factor a considerar es la diferencia de salarios entre DBAs y Data Engineers. El DBA es un rol de IT tradicional, enfocado en administrar y cuidar los datos, mientras que el data engineer está orientado a habilitar nuevos negocios.

Tabla 2. Salario por rol

Experiencia

La figura 2 muestra una gráfica donde se aprecia el salario medio de acuerdo a los años de experiencia, el tamaño de la burbuja indica el tamaño de la muestra para cada punto. Como podemos apreciar, el salario percibido tiene una relación importante con la experiencia. Durante los primeros 7 años, la relación es prácticamente lineal, con un crecimiento aproximado de 5 mil pesos por año de experiencia. A partir del octavo año de experiencia el salario se estabiliza alrededor de los 40 mil pesos.

Figura 2. Salario de acuerdo a años de experiencia

Ubicación geográfica

La tabla 3 muestra el salario medio de acuerdo a la ciudad donde radica la persona. Solamente hemos incluido ciudades de donde obtuvimos al menos 10 observaciones.

Tabla 3. Salario por ciudad

Aparecen a la cabeza ciudades del norte del país como Tijuana, Chihuahua y Hermosillo. La muestra de participantes en estas ciudades es relativamente pequeña y muy probablemente se concentre en unas pocas empresas, pero aún así vale la pena notar este fenómeno, ya que el grueso del desarrollo de software que se hace en estas ciudades es bajo esquema nearshore para clientes norteamericanos, y el tipo de cambio monetario les permite pagar salarios por encima del resto del país. Similar es el caso de Colima, que ya hemos comentado anteriormente.

Fuera de esto, lo que encontramos es una continuación de lo que hemos visto en años anteriores: entre las ciudades grandes, Guadalajara se mantiene con los mejores sueldos, por delante de Monterrey y Ciudad de México. Querétaro es otra ciudad con gran actividad pero ofrece salarios significativamente menores que las ciudades previamente mencionadas, en gran parte porque el grueso de la actividad en esta ciudad es en centros de desarrollo para grandes corporativos que tienen grandes volúmenes de trabajo pero pagan tarifas mucho menores que los clientes nearshore.

La tabla 4 muestra un comparativo de salarios entre distintos países. Descartamos aquellos países de donde se obtuvieron menos de 5 respuestas. Aunque la muestra en países distintos a México es demasiado pequeña como para poder generar información confiable, sí se nota claramente la brecha salarial entre Estados Unidos y Latinoamérica.

Tabla 4. Salario por país

Estudios

La tabla 5 muestra el desglose de salario de acuerdo al máximo nivel de estudios terminado.

Tabla 5. Salario por nivel de estudios

Lo primero que llama la atención es que el salario medio de personas cuyo máximo nivel de estudios es de preparatoria o vocacional sea mayor que el de graduados universitarios. Habrá quienes quieran ver esto como una señal de que no sirve ir a la universidad, pero hay que tomar este dato con precaución. Por un lado, la diferencia es pequeña y depende de si nos basamos en la mediana o la media para ver cual queda arriba. Por otro lado, todos conocemos casos como estos, de personas que son muy buenas técnicamente desde jóvenes y comienzan a trabajar desde que salen de la preparatoria y ya no completan sus estudios universitarios. Estas personas típicamente ganan bien porque están acostumbrados a aprender por su cuenta, y esa es una capacidad bastante útil independientemente de si fuiste a la universidad o no.

Para ahondar más en este punto, este año agregamos a la encuesta una pregunta para conocer donde aprendieron las personas a desarrollar software, si fue por su parte, en la universidad o de otra manera como en cursos en línea o en un bootcamp / hacker school. Los resultados se pueden ver en la tabla 6.

Tabla 6a. Salario por tipo de formación (sin considerar experiencia)

En principio, podemos ver que las personas que se consideran autodidactas tienen un salario significativamente mayor que el resto. Aunque esto se podría interpretar en principio como “no tiene caso ir a la universidad”, al revisar este grupo de autodidactas encontramos que el 84% tiene estudios universitarios e incluso el 20% tiene estudios de posgrado. Entonces, no es que “no tenga caso ir a la universidad”, sino que no puedes depender solamente de lo que aprendas en la universidad, los buenos desarrolladores aprenden de forma continua el resto de su carrera.

Otro aspecto interesante a revisar sobre esta información es qué tanto varía la compensación entre quienes aprendieron a construir software en la escuela tradicional y aquellos que aprendieron mediante cursos en línea y bootcamps. Un primer vistazo nos diría que hay una diferencia significativa, dado que el salario medio de quienes aprendieron con cursos en línea es alrededor de 30% menor que el de quienes aprendieron en la universidad (y la diferencia respecto a hacker schools es todavía mayor). Sin embargo, este análisis no es confiable ya que la variable que más efecto tiene en el salario de profesionistas de software es la experiencia, y los cursos en línea son algo que apenas se ha popularizado en los últimos años, por lo que las personas que aprendieron de esta forma en general tienen menos experiencia que los que aprendieron de forma tradicional.

Así que hicimos un segundo corte, tomando en cuenta solamente a las personas con 5 años o menos de experiencia (ver tabla 6b).

Tabla 6b. Salario por tipo de formación considerando experiencia

Básicamente, al agrupar en el mismo rango de experiencia la diferencia de compensación entre escuela tradicional y cursos en línea se elimina. Esto es un hallazgo muy importante.

A continuación combinamos otra variable relevante, que es el nivel de inglés. Hicimos un recorte adicional considerando solamente a las personas que tienen un nivel de inglés de 3 o mayor según la escala ILR. Este nivel es el recomendado para poder desempeñarse profesionalmente.

Tabla 6c. Salario por tipo de formación considerando experiencia e inglés

Estos resultados nos hacen ver que el salario al que aspira un desarrollador de software no es afectado por donde haya aprendido a desarrollar. Existen otras variables que sí afectan el salario, como la experiencia o el nivel de inglés, pero dónde aprendiste a desarrollar no es una de ellas.

En el caso específico de las hacker schools, pareciera que son la opción menos atractiva en términos de compensación. Sin embargo, son algo que apenas tiene poco tiempo en nuestra región, por lo que la muestra es pequeña y en su mayoría son personas con poca experiencia construyendo software. Continuaremos monitoreando esta variable en el futuro para observar su comportamiento.

Tipo de empresa y esquema

La tabla 7 muestra la descomposición de los participantes de acuerdo al tipo de organización en la que laboran.

El comportamiento es muy similar al de los últimos años. Los salarios más altos son los de startups y los más bajos los de instituciones educativas, mientras que donde hay más empleo es en empresas proveedoras de servicios TI (ej. outsourcing) y posteriormente en empresas cuyo giro no es TI (ej. corporativos). Respecto a años anteriores, el salario en empresas proveedores e ISVs se mantuvo prácticamente igual mientras que en los corporativos aumentó ligeramente, posiblemente como consecuencia de iniciativas de transformación digital que están requiriendo contar con una mayor cantidad de talento técnico “in-house”. Nos mantendremos al pendiente de cómo evoluciona este comportamiento.

Tabla 7. Salario por tipo de empresa

Más allá del tipo de organización, algo que hay que considerar es si esta le vende a mercado nacional o internacional. Como podemos ver en la tabla 8, las personas que trabajan en empresas con clientes internacionales tienen mucho mejores salarios.

Tabla 8. Clientes locales vs internacionales

Género

La tabla 9 muestra el salario medio desglosado por género. Los resultados son prácticamente los mismos que desde que comenzamos a realizar esta encuesta hace más de diez años: no logramos rebasar el 16% de participación de mujeres, y su salario se mantiene cerca de 25% menor que el de sus contrapartes masculinas. Lo que sea que estamos haciendo como industria, no es suficiente. Necesitamos hacer más.

Tabla 9. Representación y salario de hombres vs. mujeres

Conocimientos

La tabla 10 muestra cómo varía compensación de acuerdo al dominio del idioma inglés. Una vez más se comprueba que este es el conocimiento más importante en nuestra profesión y con mayor impacto en la compensación.

Tabla 10. Salario por nivel de inglés

Veamos a continuación cómo se comporta el salario dependiendo de las herramientas y tecnologías que utiliza la persona para hacer su trabajo. Además de la compensación, es muy interesante en cada caso ver el tamaño de la muestra para comparar la adopción de cada tecnología.

Lenguaje de programación. Elixir y Go han cobrado popularidad entre desarrolladores experimentados enfocados al back-end, y esto se refleja en el salario medio de quienes lo usan. Otro caso notable es el de Python, que sin ser un lenguaje nuevo ha ganado bastante popularidad en tiempos recientes, impulsado especialmente por su uso para procesamiento de datos. El resto se mantiene similar a años anteriores: JavaScript es el lenguaje más usado seguido de Java y C#, y PHP se mantiene en el último peldaño de compensación.

Tecnología front-end. En el caso de los front-end frameworks, Ember y Cocoa se mantienen como frameworks de especialidad, bien compensados. React continúa creciendo significativamente, y ya no está tan lejos de Angular en cuestión de utilización, siendo que este último le lleva varios años de ventaja.

Infraestructura. Podemos ver la importancia que está tomando aprender a manejar infraestructura en la nube, especialmente usando herramientas como Kubernetes y Ansible. En cuanto a los proveedores cloud, comprobamos que AWS lleva la delantera en adopción.

Certificaciones. Las certificaciones orientadas al negocio, como Business Analyst o Enterprise Architect se mantienen con la mayor compensación, por encima de los PMPs que fueron los reyes anteriormente. En cuanto a las certificaciones técnicas, la de Arquitecto de soluciones de AWS parece ser la más valorada.

Tabla 11. Desglose por lenguaje de programación.

Tabla 12. Desglose por tecnología front-end.

Tabla 13. Desglose por plataforma de infraestructura.

Tabla 14. Desglose por certificación.

Comentarios

Really helpful post

Really helpful post! There is a great deal of info right here that can aid any company obtain started with a successful social networking campaign. roku.com/link

This is a wonderful article

First You got a wonderful blog site.
I will have an interest in more similar topics. I see you obtained really extremely useful topics,
i will be always examining your blog site thanks. kbc lottery

This is a wonderful article

I obtained excessive interesting stuff on your blog.
I presume I am not the only one having all the pleasure right here!
Maintain the good work. kbc lottery winner

This is a wonderful article

Terrific task below on.
I review a great deal of article, however I never ever heard a topic similar to this.
I Love this topic you made regarding the blog owner's bucket checklist. Extremely clever. kbc lottery

This is a wonderful article

Good blog post but I was wondering if you could create a little much more on this topic?
I 'd be extremely appreciative if you can elaborate a bit additional.
Value it! kbc number

This is a wonderful article

I'm sure that you will be making a really beneficial location.
Good do! kbc lottery winner

This is a wonderful article

These certain papers amazing,
and My partner and I appreciate each of the execute that you have actually put right into this.
I'm certain that you will certainly be making a truly beneficial place.
I have actually been furthermore delighted. Excellent perform! jio lottery winner

This is a wonderful article

Great Article it's cutting-edge and also truly informative maintain us published with new updates.
its was truly valuable. thanks a great deal. best email marketing software for small business

Really helpful post

I'm sure that you will be making a really valuable location.
Good do! Anaesthesia Solutions

This is a wonderful article

Think it or otherwise,
it is the sort of details I've long been looking for.
It matches my requirements a lot.
Thank you for writing this information. jio lottery winner 2020

This is a wonderful article

You have actually done a fantastic job on this write-up.
It's really understandable and also very smart. You have actually even taken care of to make
it understandable as well as very easy to check out. You have some actual composing ability.
Thank you. kbc lottery 2020

asda e cigs

Very nice article, I enjoyed reading your post, very nice share, I want to twit this to my followers. Thanks!. e cigarette asda

This is a wonderful article

I want you to give thanks to for your time of this fantastic read!!!
I certainly enjoy every little of it and I have you bookmarked to have
a look at new things of your blog a must-read blog site! Packwoods

head up display

I will be interested in more similar topics. i i will be always checking your blog thanks head up car display

a must-read blog!

I desire you to give thanks to for your time of this terrific read!!! I most definitely appreciate every bit of it and also I have you bookmarked to look into new stuff of your blog site a must-read blog! kbc head office number

This is a wonderful article

No question this is an outstanding post I obtained a great deal of understanding after reading all the best. The style of the blog is excellent there is virtually everything to check out, Brilliant post. kbc winner

This is a wonderful article

I can not wait to dig kickoff and deep utilizing sources that I got from you. Your liveliness is rejuvenating. kbc helpline number

a must-read blog!

The most effective post I came throughout a number of years, write something about it on this web page. kbc customer care number

a must-read blog!

Great Article it's actually informative and innovative maintain us posted with brand-new updates. its was actually useful. thanks a whole lot. kbc winner list

Wonderful blog

Wonderful blog site! Do you have any kind of pointers as well as hints for aspiring writers? I'm intending to start my own website soon but I'm a little shed on everything. Would certainly you propose starting with a cost-free platform like WordPress or go with a paid option? There are a lot of alternatives out there that I'm totally overwhelmed. Any kind of recommendations? Many many thanks! jio lottery winner 2021

Fabulous article

Fabulous article, you have actually denoted out some wonderful points, I also think this s an extremely terrific internet site. I will see again for more quality material as well as also, recommend this site to all. Thanks. kbc lottery 2021

Actually impressed!

Whatever is extremely clear as well as really open clarification of problems. It consists of real facts. Your internet site is very important. Many thanks for sharing. fildena

The American Crisis…

The American Crisis Prevention and Management Association has been providing crisis prevention, intervention and management training, certification, consulting that help individuals and organizations for over a decade. MAB Certification Course Online

a must-read blog!

Really amazed! Everything is extremely clear and also extremely open clarification of problems. It contains real realities. Your internet site is extremely useful. Thanks for sharing. how to find a company

Outstanding blog post.

Outstanding blog post. I was always checking this blog, and I'm amazed! Very useful information particularly the tail end, I care for such information a great deal. I was exploring this specific info for a long time. Many thanks to this blog my expedition has actually ended. kbc lottery winner 2021

I can not wait to dig…

I can not wait to dig kickoff and deep using sources that I received from you. Your spirit is revitalizing. kbc winner list

Effectively composed details…

Effectively composed details. It will certainly pay to anybody who utilizes it, counting me. Maintain the great. For sure I will certainly assess out even more blog posts an everyday. jio lottery

I truly delighted in reading…

I truly delighted in reading this article, large fan. Maintain up the great and also please inform me when can you release extra write-ups or where can I find out more on the topic? jio winner

You obtained a fantastic…

You obtained a fantastic blog. I will certainly want more comparable subjects. I see you got really extremely helpful subjects, I will be constantly examining your blog site many thanks. kbc lucky winner 2021

I review a lot of blog site…

I review a lot of blog site messages, yet I never heard a subject like this. I Love this topic you made regarding the blogger's container list. kbc head office number

Pretty wonderful post. I…

Pretty wonderful post. I just came across your weblog and also wished to state that I have actually appreciated browsing your blog articles. Besides, I'll be signing up for your feed as well as I wish you create once again quickly! kbc lottery winner

Think it or otherwise, it is…

Think it or otherwise, it is the kind of information I've long been looking for. It matches my requirements a whole lot. Thank you for creating this info. self care

Pretty good blog post

Pretty good blog post. I simply came across your weblog and also wanted to state that I have actually truly taken pleasure in surfing your post. I'll be subscribing to your feed and also I wish you compose again soon! 먹튀검증

No question this is an…

Think it or otherwise, it is the type of information I've long been attempting to discover. It matches my needs a great deal. Thanks for writing this details. buy opdivo online

I want you to thank for your…

I want you to thank for your time of this terrific read!!! I certainly take pleasure in every little bit of it and also I have you bookmarked to have a look at brand-new stuff of your blog a must-read blog! investigadores privados Madrid

Really helpful post

Believe it or not, it is the kind of details I've long been attempting to locate. It matches my demands a lot. Thank you for composing this information. ytmp3

This is an amazing post I…

This is an amazing post I have seen due to the deal it. It is really what I expected to see count on the future you will certainly proceed in sharing such a mind-blowing message. 悉尼代写

it looks wonderful.

Hi there, I found your site by means of Google while looking for a related subject, your internet site turned up, it looks wonderful. I have bookmarked it in my google book markings. windows 7 download

Routine brows through…

Routine brows through provided right here are the easiest method to appreciate your energy, which is why I am going to the site everyday, looking for new, interesting details. Thanks! kbc lottery winner 2021

Actually amazed! Everything…

Actually amazed! Everything is very clear and also really open clarification of issues. It consists of real facts. Your site is really beneficial. Many thanks for sharing. vodafone lottery winner

Truly amazed! Whatever is…

Truly amazed! Whatever is very clear and also really open clarification of problems. It consists of true facts. Your website is really valuable. Thanks for sharing. ויאגרה בלי מרשם

Keep up the great job; I…

Keep up the great job; I review a couple of blog posts on this internet site, including I take into consideration that your blog site is fascinating as well as has sets of great item of info. Many thanks for your useful initiatives. https://kstreamingvf.fr/

I review a great deal of…

I review a great deal of blog site posts, yet I never heard a topic like this. I review a great deal of blog site articles, but I never listened to a subject like this. Positive site, where did u come up with the information on this posting? I simply stumbled upon your weblog as well as wanted to say that I have really appreciated browsing your blog articles. Positive website, where did u come up with the info on this uploading? jio lottery

Extremely insightful article…

Extremely insightful article! There is a great deal of details below that can assist any type of business start with a successful social networking project. kbc lottery 2021

a must-read blog!

Fabulous message, you have actually represented out some superb factors, I furthermore think this s an extremely fantastic internet site. I will certainly check out again for more quality material and also, advise this site to all. Many thanks. GTA San Andreas PC Game Download

Great job right here on. I…

Great job right here on. I read a lot of blog articles, however I never heard a subject like this. I Love this subject you made concerning the blog owner's pail list. Extremely clever. kbc head office number

Good message yet I was…

Good message yet I was wondering if you could compose a little bit extra on this topic? I would certainly be extremely happy if you could clarify a little bit further. Appreciate it! kbc check lottery no

Amazing blog site! Do you…

Amazing blog site! Do you have any kind of pointers as well as hints for aiming writers? I'm planning to start my own website quickly however I'm a little lost on whatever. Would you propose starting with a free platform like WordPress or go for a paid option? There are numerous alternatives available that I'm entirely overwhelmed. Any pointers? Many thanks! quiz代做

Fabulous message, you have…

Fabulous message, you have actually signified out some superb points, I also believe this s a really fantastic internet site. I will visit once again for more top quality web content as well as likewise, recommend this website to all. Many thanks. paragonpoker

Many thanks for sharing nice…

Many thanks for sharing nice info with us. I like your post as well as all you show us is up to date and rather helpful, I want to bookmark the web page so I can come below again to review you, as you have actually done a remarkable task. Hppoker

Las Mejores Empresas para Trabajar en Software 2018-2019

Ivett Sanchez — Tue, 15 Jan 2019 21:56:49 +0000

Las Mejores Empresas para Trabajar en Software 2018-2019

Ivett Sanchez Tue, 01/15/2019 - 15:56

Publicado en

SG #58

Las Mejores Empresas para Trabajar en Software 2018-2019

A través de la iniciativa “Best Place to Code”, Software Guru identifica y reconoce a las empresas que se esfuerzan por brindar las mejores condiciones de trabajo y carrera para los profesionistas de software en nuestra región.

A diferencia de las listas generadas en años anteriores por Software Guru, a partir de este año hemos formalizado el proceso de evaluación y establecido controles para asegurar que las personas que participan sí colaboran actualmente en la empresa.

Proceso de evaluación

La evaluación se realizó por medio de un cuestionario contestado por los colaboradores de cada empresa, que considera cinco categorías:

Compensación económica, que toma en cuenta tanto el salario como prestaciones adicionales, la posibilidad de adquirir participación (stock options), y el proceso para revisar y ajustar la compensación.
Desarrollo profesional, donde se incluyen aspectos como planes de carrera, capacitación, mentoría entre pares, y vinculación hacia el exterior de la organización.
Cultura laboral, que mide aspectos como el ambiente de trabajo, la relación con los superiores, la forma en que se resuelven conflictos, y la responsabilidad social.
Diversidad y equidad de género, para identificar a las organizaciones que brindan las mejores condiciones a mujeres y personas de género no binario.
Infraestructura, que considera aspectos como la ubicación de las oficinas, instalaciones, y disponibilidad de herramientas de trabajo.

Las evaluaciones se realizaron durante el 4to trimestre del 2018, y participaron 33 empresas. De estas, solamente 26 obtuvieron el puntaje necesario para ser acreditadas como “Best Place to Code”.

El top 20

A continuación compartimos la lista “top 20” de Best Place to Code, es decir las 20 empresas que fueron mejor evaluadas por sus colaboradores.

La lista está ordenada en base al resultado de la evaluación, siendo el número 1 la empresa que obtuvo la mejor evaluación.

Headspring
Grow IT
michelada.io
GIN Group Integra
Simpat
DigitalOnUs
OnceDev
TangoSource
Ordico
BBVA Bancomer
Nova Solutions
iTexico
Tacit Knowledge Guadalajara
Abraxas Ventures
Platzi
Scio Consulting
Svitla Systems
CONTPAQi
Intelimétrica
Experiencias Xcaret

Felicitamos a estas empresas que a través de su liderazgo y esfuerzo han logrado ser parte de este muy selecto grupo. En Software Guru estamos convencidos de que los profesionistas de software pueden encontrar “trabajos de ensueño” en nuestra región, y estas empresas son prueba de ello.

Esperamos que el ejemplo que ponen estas organizaciones motive al resto de nuestra industria para seguir mejorando y que entre todos logremos atraer el talento que necesitamos, ya sea de otras profesiones, países, o jóvenes que están decidiendo qué estudiar.

Te invitamos a conocer sobre estas y otras empresas que han demostrado ser Best Place to Code en https://bestplacetocode.com. También tendrás oportunidad de conocerlas en persona en el “Best Place to Code showcase” que se realizará el 27 de febrero en Ciudad de México.

OpenMarket Considera su Presencia en Guadalajara como Clave de su Éxito

Ivett Sanchez — Tue, 15 Jan 2019 21:42:15 +0000

OpenMarket Considera su Presencia en Guadalajara como Clave de su Éxito

Ivett Sanchez Tue, 01/15/2019 - 15:42

Publicado en

SG #58

Han pasado sólo dos años desde que OpenMarket abrió una oficina en Guadalajara Jalisco, México, y el equipo ya tiene mucho que celebrar. En sólo dos años, el personal creció hasta formar cuatro equipos de desarrollo, uno de soporte y varios roles técnicos más. La empresa tiene el plan de expandirse un 40% adicional el siguiente año.

OpenMarket, que desarrolla soluciones de mensajería utilizando las tecnologías SMS, MMS y RCS para las empresas más importantes del mundo, planea en el corto plazo añadir muchos puestos más en su oficina de Guadalajara.

"En el año 2016, cuando me pidieron que abriera una nueva oficina, me sentí muy emocionado por el reto,” comentó Jairo Narez, quien es gerente de desarrollo de software y líder del site en Guadalajara. “Las metas eran muy ambiciosas, pero el equipo global fue muy solidario y nos brindaron todo su apoyo. Personas de las diferentes oficinas en el mundo viajaron a México en varias ocasiones, para ayudar en todo lo necesario”.

¿Cómo puede una compañía expandirse tan rápidamente? Sus ingenieros opinan que es por su ambiente tan favorable para un desarrollador. “Lo que me gusta es que soy dueño de todas mis aplicaciones,” comenta Ramón Obeso, quien es uno de los fundadores de la oficina y el primer desarrollador de software contratado en Guadalajara. “En OpenMarket no estamos atrapados en silos, en una tecnología en particular o en una sola forma de hacer las cosas. No estamos encadenados a un tipo de base de datos o framework, o lenguaje de programación. Aquí tenemos la libertad de utilizar lo que el caso de uso requiera. Eso me encanta, porque me ha forzado a aprender nuevas tecnologías, que de otra forma no conocería.”

Una de las razones por la cual los proyectos en OpenMarket son tan interesantes, es porque muchos de los clientes que utilizan nuestra plataforma están en el top diez de las marcas más reconocidas a nivel mundial. Utilizando nuestra plataforma de mensajería, estas compañías envían más de tres mil millones de mensajes al mes a sus clientes en todo el mundo.

“Aunque la mayoría de la gente en Guadalajara no ha escuchado acerca de OpenMarket, cuando les dices lo que hacemos y quiénes son nuestros clientes, se impresionan. Nuestro trabajo tiene un impacto real en la vida diaria de las personas, y es muy lindo sentirse parte de eso,” dijo Diana Contreras, desarrolladora de software senior.

OpenMarket es una empresa única en México, porque aprovecha todo el talento de los equipos de desarrollo ubicados en Guadalajara. “Nuestros equipos de ingeniería construyen sus productos y son dueños del proceso de desarrollo de software de principio a fin. Esto incluye arquitectura, diseño, desarrollo, pruebas, puesta en producción y soporte de los servicios por los que son responsables”, enfatizó Narez.

Pero lo que mantiene a los ingenieros de OpenMarket tan felices, no son solo clientes fascinantes y proyectos interesantes. El tamaño de la oficina de Guadalajara, así como la cultura de la compañía, son también muy importantes. Narez piensa que en OpenMarket es muy fácil conocer a todos muy bien. “Operamos como un grupo muy unido. Realmente nos importa la gente con la que trabajamos.”

OpenMarket le da mucho valor a un balance saludable entre la vida personal y profesional, y alenta la socialización de sus colaboradores sin importar en cuál de sus cinco oficinas en el mundo se encuentren. En la oficina de Guadalajara, por ejemplo, los últimos jueves de cada mes se organiza una salida en grupo ya sea a un pueblo mágico cercano, a escalar, al cine, a jugar juegos de mesa o a comer en el lugar de moda.

La ubicación de OpenMarket en Guadalajara ayuda a que sea fácil pasar un rato divertido con el equipo. La empresa está ubicada en un edificio corporativo, en el corazón de Guadalajara y dentro de la afamada Plaza Galerías. A la hora de la comida, vamos a la plaza por comida, a hacer compras o al banco. “Es como si OpenMarket tuviera gimnasio, restaurantes y cine, porque todo está aquí,” expresó Contreras.

Otro beneficio de la compañía es su tamaño. OpenMarket es una empresa mediana, con 300 empleados en el mundo. Narez explica, “En algunos lugares, eres un número más. En otros, tienes que tener un ojo en tu trabajo y otro en las noticias, para ver si tu compañía logró asegurar la siguiente ronda de financiamiento. En OpenMarket, no tenemos ninguno de esos problemas. Tenemos lo mejor de los dos mundos.”

OpenMarket debe gran parte de su estabilidad a su empresa matriz, Amdocs. Cotizando en bolsa como una de las más importantes empresas proveedoras de software y servicios en el sector de las telecomunicaciones y medios de comunicación, Amdocs tiene una fuerza laboral de más de 25,000 personas, y obtuvo ingresos por cerca de cuatro mil millones de dólares el año pasado. Debido al tamaño y madurez de Amdocs, los empleados de OpenMarket disfrutan de los recursos y beneficios que sólo una compañía grande y exitosa puede ofrecer, incluyendo un excelente seguro de gastos médicos, vales de despensa y restaurante, y presupuesto para viajes de negocios a otras oficinas de OpenMarket alrededor del mundo.

La naturaleza global de la empresa, también es un gran punto a favor para los empleados. Además de estar en Guadalajara, OpenMarket tiene oficinas en Seattle, Detroit, Londres, Pune y Sídney. Los colaboradores de cada una de las oficinas de OpenMarket, asisten a conferencias, como por ejemplo, Amazon´s AWS re: Invent en Las Vegas, y también trabajan juntos a diario.

Una cosa muy importante en todo OpenMarket es su compromiso con la diversidad. En Guadalajara, el equipo está haciendo muchas cosas para reclutar talento con diversidad e inclusión. Por ejemplo, se lanzan campañas en Glassdoor y LinkedIn con anuncios enfocados en atraer candidatos de diversos perfiles, y se organizan eventos para atraer becarios de universidades reconocidas por tener estudiantes de diferentes comunidades. La oficina de Guadalajara, tiene su propio grupo de Diversidad e Inclusión, que se organiza con escuelas para promover la misma. Hasta la fecha, estos esfuerzos han dado muchos frutos: el 24% del personal técnico en Guadalajara son ingenieras.

Pero no todo son números. Una vez que un candidato es contratado, OpenMarket sabe que el esfuerzo real es hacer que el nuevo compañero se sienta incluido. “Trabajando en OpenMarket, nunca he sentido ninguna diferencia en cómo soy tratada,” comentó Contreras. “Me gusta que soy tratada como un individuo. Me gusta que siempre que hablo, sé que mis compañeros, hombres y mujeres, me escuchan.” Diana, quien ha estado en OpenMarket por dos años, fue promovida a una posición senior un año y medio después de haber entrado a la empresa.

Y al tiempo que OpenMarket mira hacia el 2019, Jairo Narez visualiza a la compañía seguir en su exitosa trayectoria, debido en gran parte a su cultura única. “En OpenMarket puedes ser auténtico. Para mí eso es muy valioso. Todos tenemos fuerzas y debilidades, y aquí no tienes que fingir ser alguien más. Los conflictos se resuelven entendiendo las diferentes perspectivas.” Elsa Sainz, Coordinadora de Atracción de Talento, está de acuerdo, y agrega, “En OpenMarket, eres parte de una gran familia. En vez de estar con colegas, estás con amigos – puedes contar con ellos para reír, para estar serio, y para dar y recibir ayuda.”

¿Estás interesado en unirte a la familia OpenMarket? Ingresa a nuestro sitio web y revisa las posiciones que tienen abiertas. https://www.openmarket.com/company/careers/

El impacto de los lenguajes propietarios de propósito particular: Una visión panorámica

sg — Tue, 15 Jan 2019 20:51:47 +0000

El impacto de los lenguajes propietarios de propósito particular: Una visión panorámica

sg Tue, 01/15/2019 - 14:51

Publicado en

SG #58

Prueba de Software

Autor

Luis Vinicio León Carrillo

Suele ser difícil percibir el impacto que tienen los lenguajes en nuestra civilización, pues es algo que vivimos cotidianamente. En el ámbito de los lenguajes naturales, Koen DePryck (en su libro sobre “The Ontology of Language”) nos dice:

“Our language has its historical roots in the world, so that the history of the world is the history of our language, and so that the world is language.”

Ya en nuestro campo, el reconocido computer scientist C.A.R. Hoare comentó en algún momento, refiriéndose a su método de ordenamiento Quick-Sort y después de tomar un curso de Algol-60 (primer lenguaje en ofrecer la posibilidad de escribir subrutinas recursivas):

“It was there that I first learned about recursive procedures and saw how to program the sorting method which I had earlier found such difficulty in explaining.”

Los lenguajes nos proveen de muchas estructuras que facilitan que hagamos eficientemente muchas cosas, pero que al mismo tiempo pueden dificultar ver otras que pudieran ser igualmente importantes. Las estructuras que tenemos a nuestra disposición en un lenguaje (sea artificial o natural) pueden imponer límites a lo que podemos expresar (sea programar o pensar).

En los últimos números de esta columna hemos abordado los lenguajes formales desde distintos puntos de vista, buscando generar el contexto para mostrar la utilidad y el impacto de contar con lenguajes propietarios en nuestras organizaciones para documentar, especificar, programar, o probar productos de software. En el caso de la programación, el contar con un lenguaje propietario de más alto nivel que el que usa actualmente una organización permitiría destinar más tiempo al diseño del producto que a la escritura del programa, lo que facilitaría el incremento de la calidad; al no ser necesario atender tantos detalles, habría menos probabilidad de introducir errores, lo cual también facilitaría el incremento de la calidad; y al ser estos lenguajes más expresivos, se podría entregar el producto más rápidamente, facilitando el incremento de la productividad.

En este número abordaremos un ejemplo con el que buscaremos evidenciar los beneficios anteriores. Para ofrecer aquí la idea adecuadamente, permítannos primero retomar los puntos más relevantes que expusimos en otros números y que contextualizan la presentación del ejemplo.

1. Lenguajes - Patrones

Comenzamos abordando el concepto “lenguaje” como algo muy general, en términos de “patrones” en SG#48 (“el número 48 de la revista”):

En la figura de abajo, consideren que la sustitución de lo que está a la izquierda del símbolo “⇒” por lo que está a su derecha ocurre siempre “en paralelo”; es decir: que todas las apariciones de lo que está a la izquierda de “⇒” deben sustituirse por lo que está a la derecha simultáneamente.

Si aplicamos 3 veces esa regla/patrón (en paralelo) tenemos:

Como pueden observar, este pequeño patrón, descrito con esa sencilla y única regla, parece describir el crecimiento de una planta (solo en 2 dimensiones). Lenguajes en los que las reglas se aplican en paralelo, se han utilizado para describir fenómenos de este tipo, y han dado lugar a toda una jerarquía de lenguajes conocida como Sistemas Lindenmayer (L-Systems), los cuales a su vez tienen relación con los fractales (“el todo contenido en cada parte”).

2. Lenguajes formales

Luego, en SG#50, abordamos “lenguaje” desde una perspectiva más bien matemática (algebraica):

Partimos de la definición del concepto de alfabeto como un conjunto finito de caracteres B = { b1 , b2 , …, bm } , y dijimos que B tiene una cardinalidad (cantidad de elementos) igual a m , lo cual escribimos como |B| = m .

Definimos la operación de concatenación “ ⋅ ” sobre caracteres (lo que nos permite construir b5 ⋅ b4 ⋅ b8 ⋅ b8 ) y sobre conjuntos de caracteres (lo que nos permite construir B ⋅ A ⋅ D ).

Luego definimos la exponenciación de la concatenación Bx sobre un alfabeto B como la aplicación de la concatenación x-1 veces sobre el alfabeto ( B ⋅ B⋅ … ⋅ B , donde B aparece x ≥ 0 veces).

Después definimos la cerradura de Kleene B* como la unión de todas las exponenciaciones sobre el alfabeto B (B* = U∞i=0 Bi ).

Finalmente definimos que un lenguaje formal sobre un alfabeto B es cualquier subconjunto de B*. Definimos la cerradura positiva B+ como B+ = B ⋅ B* (B+ contiene cadenas con al menos un caracter).

Explicitamos que, dado un código ASCII extendido que aquí llamaremos AE, que extienda el usado hoy en día con cualquier cantidad (finita) de caracteres, podemos ver al lenguaje Java como el subconjunto de cadenas de cualquier longitud escritas utilizando ese AE que son aceptadas como “correctas” por el compilador de Java. Lo mismo es cierto si sustituimos “Java” por el nombre de cualquier lenguaje de computación.

En AE* están incluidos no solo todos los lenguajes de programación existentes y por existir, sino también todos los compiladores (escritos y por escribirse) de todos esos lenguajes. De hecho, en AE* se encuentran todas las cadenas de caracteres que podamos escribir en esa extensión del ASCII, incluyendo los programas “incorrectos” en todos los lenguajes.

Dijimos que dado un conjunto A que tiene i elementos, la cantidad de subconjuntos que pueden formarse sobre A es igual a 2i . Dijimos también que B* , la Cerradura de Kleene sobre el alfabeto B, es un conjunto infinito pero contable, porque tiene la misma cardinalidad que el conjunto de los números naturales N. Esto implica en particular que, así como ocurre en el conjunto de los números naturales N, dada una de las cadenas de B* , siempre podemos definir cuál es la que le sigue y listar sus elementos en orden sin saltarnos alguno (en N , dado un número natural y, sabemos que el que le sigue es y+1).

De lo anterior se sigue que la cantidad de lenguajes sobre cualquier alfabeto B es igual a 2N … El asunto es que 2N es una cardinalidad estrictamente mayor que la de N (siguiendo el Teorema de Cantor), lo que lo vuelve un conjunto no-contable (aquellos conjuntos en los que, dado un elemento x, no es posible decir cuál elemento es el que sigue, como en el caso de los números reales R: si tenemos el número 0.0004 no podemos decir que el que le sigue es 0.0005; tampoco que es 0.00041; en realidad, entre cualesquiera 2 números reales hay una cantidad infinita de números reales).

Una consecuencia importantísima de lo anterior es que la cantidad de lenguajes (=2N) que pueden definirse sobre un alfabeto es estrictamente mayor que la cantidad de cadenas (=N) que pueden construirse sobre ese alfabeto, así es que: independientemente del tamaño del alfabeto, siempre tendremos lenguajes sobre ese alfabeto para los que no podemos definir un compilador, esto es, siempre habrá lenguajes que no podremos procesar.

3. Gramáticas

En SG#51, revisamos “lenguaje” desde un punto de vista un poco más “computacional”, pero aún “declarativo”, utilizando reglas (que pueden verse como una abstracción del concepto de patrón):

Dijimos que podemos definir lenguajes utilizando gramáticas, las cuales son cuátruplas de la forma:

〈 T, N, S0 , R 〉 donde

T es el conjunto de los símbolos terminales del lenguaje (en adelante “Terminales”); son finalmente los elementos constituyentes de las secuencias de símbolos de una cadena del lenguaje;

λ es con lo que designamos la “cadena nula” (aquella que no contiene símbolos);

N es el conjunto de los símbolos no-terminales del lenguaje (en adelante “no-Terminales”); no constituyen necesariamente cadenas finales, pues son definidos en términos de una combinación de Terminales y no-Terminales.

Nota: En estas definiciones, debe cumplirse que T ∩ N = {} ;

R es el subconjunto del producto cartesiano (T ∪ N)* × (T ∪ N)* que define la relación matemática que denota las reglas de reescritura del lenguaje (en adelante “Reglas”);

S0 es el elemento distintivo de los no-Terminales llamado “Símbolo-inicial”, que es con el que inicia el “procesamiento” de R .

Escribimos las Reglas utilizando el “meta-lenguaje” (llamado así porque es un lenguaje con el cual definimos lenguajes) llamado BNF (Backus-Naur Form). En él, para cada regla se coloca el primer elemento del producto cartesiano, seguido del símbolo “→” seguido del segundo elemento del producto cartesiano.

4. Jerarquías de Lenguajes

Con la definición anterior, en SG#51 y SG#52 revisamos una Jerarquía de Lenguajes Formales (que dijimos, incluye la Jerarquía de Chomsky):

La siguiente categorización de lenguajes se hace considerando la complejidad de la estructura de las reglas en la R particular que los define (por cuestiones de espacio, obviaremos algunos detalles):

Llamamos gramáticas regulares a aquellas cuyas reglas en R sean de la forma A→ B d | d (o menos compleja); y llamamos lenguajes regulares (o de Tipo 3, o Lgs3 de manera corta) a aquellos que puedan definirse utilizando gramáticas regulares.
Llamamos gramáticas libres de contexto a aquellas cuyas reglas en R sean de la forma A→ α (o menos compleja), y lenguajes libres de contexto (o de Tipo 2, o Lgs2) a aquellos que puedan definirse utilizando gramáticas libres de contexto. Dentro de estos lenguajes existen varias divisiones. Una de las más relevantes es la que diferencia entre los lenguajes determinísticos y los lenguajes no-determinísticos (un ejemplo de estos últimos es an bn ∪ an b2n , que como podrán intuir, para procesarlo es necesario que el compilador asociado realice backtracking).
Llamamos gramáticas sensibles al contexto a aquellas cuyas reglas en R sean de la forma β1 A β2 → β1 α β2 (o menos compleja), donde α ≠ λ ; y lenguajes sensibles al contexto (o de Tipo 1, o Lgs1) a aquellos que puedan definirse utilizando gramáticas sensibles al contexto. Decimos que β1 y β2 representan el contexto en el que A se puede transformar en α . Ahora bien, como α ≠ λ , entonces la suma de la cantidad de Terminales y de no-Terminales en α es mayor o igual a uno; a esta cantidad la llamaremos la longitud de α y la denotamos con|α|. Ahora podemos generar una definición equivalente pero menos restrictiva (aunque no hace evidente el atributo “sensible al contexto”): Llamamos también gramáticas sensibles al contexto a aquellas cuyas reglas en R sean de la forma θ → α (o menos compleja), donde θ ∈ (T ∪ N)* , θ ≠ λ y |θ| ≤ |α| ; y llamamos lenguajes sensibles al contexto a aquellos que puedan definirse utilizando este tipo de gramáticas.
Llamamos gramáticas estructuradas por frases a aquellas cuyas reglas en R sean de la forma θ → α (o menos compleja), donde θ ∈ (T ∪ N)* y θ ≠ λ ; y llamamos lenguajes estructurados por frases (o Tipo 0, o Lgs0) a aquellos que puedan definirse utilizando gramáticas estructuradas por frases. Dentro de estos lenguajes se encuentra la importantísima clase los Lenguajes Decidibles (o Recursivos, o Lgsdec), que son aquellos para los que es posible construir programas (por ejemplo compiladores) que siempre terminan y anuncian si la cadena es elemento del lenguaje o si no lo es (aunque para ello requieran enormes cantidades de tiempo y/o memoria). Las reglas con las que se definen tienen la misma forma que los Lgs0. Podemos ver a los Lgs0 como lenguajes semi-decidibles: los programas que los procesan (por ejemplo compiladores) pueden determinar cuando las cadenas sí son elementos del lenguaje, pero cuando no es así continúan su procesamiento indefinidamente (“se ciclan”).
Llamamos Lenguajes Generales (o Lgsgral) a aquellos que incluyen a todos los anteriores y a los que no son susceptibles de ser definidos mediante reglas.

La Jerarquía muestra un crecimiento significativo en la complejidad de la estructura de las reglas (o dicho de otra manera, una disminución significativa en las restricciones sobre esa estructura). En ella ocurre (obviando algunas precisiones) que Lgs3 ⊂≠ Lgs2 ⊂≠ Lgs1 ⊂≠ Lgsdec ⊂≠ Lgs0 ⊂≠ Lgsgrals.

También revisamos los siguientes lenguajes “prototípicos” expresados en forma algebraica:

L1 : a m b n c k d i , para m, n, i, k ≥ 0 e independientes entre sí:

Se trata de una Gramática Regular. Este tipo de gramáticas tienen el mismo poder expresivo para definir lenguajes que las conocidas expresiones regulares, y son suficientes para especificar los “scanners” de los compiladores, los cuales se encargan del análisis lexicográfico.

L2 : a m b i c i d m , para m, i ≥ 0 que aparecen por pares y están “anidadas”:

Este es un ejemplo “clásico” de una Gramática Libre de Contexto.

Este tipo de gramáticas tienen el mismo poder expresivo para definir lenguajes que los conocidos grafos de sintaxis, y son suficientes para especificar los “parsers” de los compiladores, los cuales se encargan del análisis sintáctico.

L3 : a m b i c m d i , para m, i ≥ 0 , que aparecen por pares pero no están “anidadas”:

Con este tipo de lenguajes se podrían especificar (al menos buena parte de) los Sistemas de Tipos de los lenguajes de programación, los cuales definen sus aspectos semánticos (de significado, como los del paso de parámetros que mencionamos, o la equivalencia de tipos). Sin embargo, dado que el procesamiento de estos lenguajes es más complejo y costoso en tiempo que el de las Libres de Contexto, y que la mayoría de los constructos de los lenguajes de computación son de este último tipo, los aspectos semánticos se suelen abordar apoyándose en gramáticas Libres de Contexto y en una Tabla de Identificadores en la cual suele almacenarse, entre otras cosas, el nombre, la clase (si es variable, procedimiento, función, etc.), el tipo (v.gr. integer, string, 〈char, real〉 → boolean), y la dirección de cada identificador.

Después, en SG#53 mencionamos que existen también otras jerarquías de lenguajes, y revisamos la de las Left-Assotiative-Grammars:

En nuestra primera columna sobre el tema del desarrollo de lenguajes propietarios mencionamos un enfoque sobre lenguajes formales llamado Sistemas Lindenmayer (proveniente de la Biología), dado nuestro interés en encontrar mecanismos para eficientar el desarrollo de software, en números posteriores estudiamos los lenguajes formales utilizando principalmente los trabajos sobre gramáticas del lingüista Noam Chomsky, las cuales se conocen como Gramáticas Estructuradas por Frase, y en un número reciente presentamos una jerarquía de las mismas. Se presume que, en esa jerarquía, los lenguajes naturales se encuentran en la clase de los Lenguajes Sensibles al Contexto.

En realidad, las Gramáticas Estructuradas por Frase son un tipo particular de las llamadas Gramáticas Generativas, que son sistemas (“recursivos”) de reglas provenientes de trabajos en Lógica Matemática.

Algunos de los enfoques más relevantes que han sido utilizados para abordar las Gramáticas Generativas son:

Gramáticas Categóricas (“C-Grammars”): desarrolladas inicialmente en 1929 por el polaco Lesniesvsky, y aplicadas al los natural lenguajes por primera vez por Bar-Hillel en 1953.
Gramáticas Estructuradas por Frase (PS-Grammars): basadas en los “Rewrite Systems” de Emil Post desarrollados en 1936, aplicadas a los lenguajes naturales por primera vez por Chomsky en 1957.
Gramáticas Asociativas por la Izquierda (Left-Assotiative-Grammars): desarrolladas en 1985 por Roland Hausser para procesar lenguajes naturales.

Los dos primeros enfoques presentan el problema de que los recursos requeridos (tiempo y/o memoria) para hacer el procesamiento de lenguajes naturales son demasiado grandes como para llevarlos a la práctica. El tercero muestra algunas bondades al respecto.

Formalmente, una Gramática-LA (del Inglés Left-Associative Grammar, LAG) es una séptupla de la forma:

〈 W, C, LX, CO, RP, SI , SF 〉 donde

W es un conjunto finito de las llamadas Word surfaces ;

C es un conjunto finito de Category segments ;

L ⊃ ( W × C+ ) es un conjunto finito conteniendo el Léxico ;

CO = ( co1, …, con-1 ) es una secuencia finita de funciones recursivas totales (entiéndase “programas”) de (C* × C+) a (C* ∪ {⊥}) llamadas Categorial Operations ;

RP = ( rp1, …, rpn-1 ) es una secuencia finita ( igualmente larga que CO ) de subconjuntos de n ( donde n = { i | 0 ≤ i < n} ) llamada Rule Packages ;

SI = { ( cs1 rps1 ) … ( csk rpsk ) } es un conjunto finito de eStados Iniciales, donde cada c ∈ C+ y cada rp es un subconjunto de n llamado paquete de reglas de inicio;

SF = { ( cf1 rpf1 ) … ( cfk rpfk ) } es un conjunto finito de eStados Finales , donde cada c ∈ C* y cada rp ∈ RP .

Así como con las Gramáticas Estructuradas por Frase de Chomsky que estudiamos, en el conjunto de lenguajes generados por Gramáticas-LA también tenemos subclases:

Las Gramáticas-LA generales (Allgemeine (general en alemán)), o A-LAGs, corresponden a la definición de arriba.
Las Gramáticas-LA limitadas (Bounded) linealmente, o B-LAGs, son la subclase de las A-LAGs en las cuales la longitud de las categorías está limitada linealmente con respecto a la longitud de la cadena de entrada.
Las Gramáticas-LA limitadas por una constante (Constant), o C-LAGs, son la subclase de las B-LAGs en las cuales la cantidad de cálculos requerida por operaciones categóricas individuales está limitada por una constante.

Dentro de estas C-LAGs tenemos las subclases de C3-LAGs , C2-LAGs , y C1-LAGs .

La siguiente es la relación de las LAGs con la Jerarquía de Chomsky (incluimos algunos aspectos de rendimiento, que eventualmente abordaremos en números posteriores).

El conjunto de Gramáticas-LA…

generales o A-LAGs, aceptan y generan todos los Lenguajes Recursivos (o “Decidibles”), algo relevante, pues como vimos en un número anterior, en la Jerarquía de Chomsky no había un tipo de gramática específica que definiera exactamente este tipo de lenguajes.
bounded o B-LAGs, aceptan y generan todos los Lenguajes Sensibles al Contexto (LSC).
constant o C-LAGs, constan de 3 subclases:
C3-LAGs contiene los Lenguajes Libres de Contexto (LLC) más complejos y algunos LSC que son “NP-Complete” (la clase de problemas para los cuales no se han descubierto algoritmos eficientes que los resuelvan, y se piensan que no existen). Para procesar estos lenguajes se requiere tanto tiempo que hacerlo se vuelve prohibitivo en la práctica (técnicamente: requieren “tiempo exponencial”, lo que significa que pueden procesarse en un tiempo expresado como una base elevada a un exponente el cual está en función de la cantidad de datos de entrada).
C2-LAGs contiene varios LLC “no-deterministas” (su procesamiento implica backtracking) y varios LSC simples. Para procesarlos se requiere tiempo polinomial.
C1-LAGs contiene todos los LLC “deterministas” (no requieren backtracking para procesarlos) y varios LSC simples. Su procesamiento solo requiere tiempo lineal, lo que los vuelve muy útiles en la práctica.

Dijimos que se piensa que en esta jerarquía, los lenguajes naturales están dentro de la clase C1-LAG, lo cual significaría que su procesamiento sí puede realizarse en la práctica, aún con altos volúmenes de datos de entrada.

5. Semántica formal

Todo el análisis anterior estuvo más bien orientado a la Sintaxis de lenguajes formales, pero en SG#56 también abordamos el tema de la Semántica de los lenguajes formales:

La sintaxis de un lenguaje –que se refiere a su estructura– es un aspecto muy importante del mismo y se utiliza ampliamente en el desarrollo de compiladores.

La “Semántica Formal” –que se refiere al significado de un lenguaje (aunque hay quien dice que “Semantics is what we have in our minds; when one writes it down, it is not semantics any more.”)– es muy importante también porque agrega precisión a la definición del lenguaje, pero actualmente no es tan común que se utilice en la construcción de compiladores (lo cual puede conducir a que v.gr. un programa dado a 2 compiladores diferentes para el mismo lenguaje tenga comportamientos distintos).

La Semántica define el significado de un lenguaje a partir de los constructos del mismo, y con ello también el de los programas escritos en él. Existen varios enfoques para hacerlo; entre los más importantes se encuentran:

El Operacional: se especifica la semántica proporcionando (el código fuente de) un intérprete que define el comportamiento de los programas de ese lenguaje. Este enfoque, al ser tan operativo, no permite razonar sobre el lenguaje (mediante mecanismos lógico-matemáticos).
El Axiomático: la semántica se especifica definiendo una “teoría matemática” para el lenguaje con la cual se puedan probar propiedades de programas escritos en ese lenguaje. Más que en lo que significa el lenguaje, el énfasis está en lo que puede probarse acerca de él.
El Denotacional: se especifica la semántica asociando a cada constructo del lenguaje un conjunto de funciones matemáticas que definen los significados denotando conjuntos. La semántica está dada en términos de conjuntos, funciones, relaciones, tuplas, predicados, y operaciones sobre estos elementos. Este enfoque tiene un nivel de abstracción aún mayor al del enfoque Axiomático.

6. Máquinas Abstractas y Lenguajes

En SG#54, tomamos un punto de vista muy procedural y revisamos el concepto “lenguaje” a la luz de las llamadas Máquinas con (conjuntos de) Estados Finitos (o Finite States Machines), MEFs, que pueden procesarlos:

Las MEFs que presentamos tienen en común que:

están constituidas por un conjunto finito de estados (S) en los que la MEF puede encontrarse cuando procesa la cadena de entrada; hay un estado inicial (ι ) en que la MEF comienza su procesamiento y un estado (h) (o más (F), dependiendo del tipo de MEF) en el (los) que puede terminarlo;
los símbolos que conforman la cadena de entrada son elementos de un conjunto finito (el “Alfabeto” A);
las operaciones de la MEF se definen mediante una relación (en el sentido matemático) de transición ρ , que toma el estado en el que se encuentra la MEF en ese momento y el símbolo actual de la cadena de entrada (y, como veremos, eventualmente otras cosas, dependiendo del tipo de MEF), y regresa el estado al que la MEF debe moverse (y eventualmente otras cosas, como veremos); si la relación de transición ρ es una función (en el sentido matemático), entonces se le denota con δ y se dice que la MEF es determinística, en caso contrario se que la MEF es no-determinística.

Vimos MEFs particulares:

Los Autómatas Finitos (AFs) (ó Finite Automata) se definen como quíntuples de la forma AF = 〈 S,ι, F, A, ρ 〉 . Pueden procesar los Lenguajes Regulares (como am bn ek d , para m, n, k, i ≥ 1 e independientes entre sí).

Los Autómatas de Pila (APs) (ó Push Down Automata) se definen como séxtuples de la forma AP = 〈 S,ι, F, A, Σ, ρ 〉 ,

en los cuales Σ es el alfabeto de la pila. Pueden procesar los Lenguajes Libres de Contexto (como ai bn en d i , para n, i ≥ 1 ).

Las Máquinas de Turing (MTs) (ó Turing Machines) se definen como séxtuples de la forma MT = 〈 S,ι, h, A, Π, ρ 〉 ,

en los cuales Π es el alfabeto de la cinta de Procesamiento. Pueden procesar los Lenguajes Estructurados por Frases.

Los Autómatas Delimitados Linealmente (ADLs) (ó Linear Bounded Automata) son MTs que para procesar una cadena solo requieren una cantidad de celdas en la cinta de procesamiento prácticamente igual a la de la cadena de entrada. Pueden procesar los Lenguajes Sensibles al Contexto (como ai bn ei d n , para n, i ≥ 1 ).

Las Máquinas de Turing que terminan (MTtsterm) son MTs que siempre culminan el procesamiento de cualquier cadena –aunque eventualmente después de mucho tiempo. Las MTsterm pueden procesar los Lenguajes Decidibles.

7. Lenguajes y Compiladores

En SG#52, asumimos una actitud más “práctica” y abordamos el concepto “lenguaje” desde la construcción de programas que los procesan y hablamos sobre la estructura y funcionamiento de los compiladores:

Obviando algunas precisiones, un compilador suele tener una estructura general como la siguiente:

Grosso modo, su funcionamiento es como sigue:

Cada vez que el scanner (Analizador Léxico) es llamado, reanuda su lectura de caracteres del Código Fuente escrito en el Lenguaje1; se salta caracteres irrelevantes (como una secuencia de comentarios, blancos, y/o saltos de línea) y luego concatena los que sí son relevantes hasta completar una cadena que tenga significado por sí misma (por ejemplo “{“, “main” y “contador” en el lenguaje C); en seguida detecta si la cadena es una palabra reservada (como “main”), un símbolo (como “{“), un identificador (como “contador”) –en cuyo caso lo busca en la Tabla de Identificadores y si no lo encuentra lo da de alta–, o un error léxico (en cuyo caso también emite el mensaje correspondiente); finalmente, regresa esta información a la subrutina que lo llamó,–usualmente el parser– conteniendo al menos 2 elementos: la cadena en sí misma (el “lexema”), y un código (el “token”) que representa el tipo genérico de la cadena (como “Identificador”, “número” o “paréntesis de cierre”).

El parser (Analizador Sintáctico) suele ser el componente central del procesamiento de un compilador. Manda llamar al scanner, el cual como dijimos regresa la cadena que acaba de completar y la información mencionada. Con esos datos, el parser busca seguir alguna de las reglas gramaticales del lenguaje; en caso de no encontrar alguna emite un mensaje de error sintáctico. En su procesamiento va utilizando y actualizando la Tabla de Identificadores (por ejemplo, escribiendo si el Identificador es el nombre de una subrutina o de una variable, así como su tipo), va construyendo el Árbol Sintáctico del programa en cuestión (ver figura abajo), y va ejecutando instrucciones que tiene “embebidas”… A) del Analizador Semántico, que entre otras cosas revisa cuestiones relacionadas con tipos de datos y paso de parámetros (para lo cual se apoya en la Tabla de Identificadores); B) del Mecanismo de Recuperación de Errores, que al detectar un error emite el mensaje correspondiente y hace lo necesario para permitir que se pueda continuar con el análisis (como saltar secciones de código “problemáticas”); y C) del Generador de Código (el cual también se apoya en esa Tabla) para construir el Código Objeto con instrucciones en el Lenguaje2 (aunque es usual generar primero código en un lenguaje intermedio, realizar un proceso de Optimización y luego generar el Código Objeto).

El árbol sintáctico para la cadena a2 b3 c3 d 2 del lenguaje L2, se muestra en la siguiente figura; en ella se se parte de S0 y se van generando ramificaciones sustituyendo no-Terminales mediante la aplicación de alguna regla de la gramática; las hojas del árbol acaban siendo Terminales o λ.

Lenguajes de Computación (LCs) y Lenguajes de Programación (LPs)

En SG#55, revisamos el concepto de “Computer Languages” como una generalización de los “Programming Languages”:

Todos estamos familiarizados con el concepto de Lenguajes de Programación (LPs) y existe bastante literatura sobre el tema. Sin embargo, si buscamos incrementar nuestra productividad deberíamos abrir nuestra panorámica y considerar no solo los LPs, sino lo que llamaremos aquí “Computer Languages” o “Lenguajes de Computación” (LCs), concepto que incluye los LPs, pero también los Lenguajes de Documentación (como LaTeX y HTML), Lenguajes de Arquitectura (como ABACUS y CBabel), Lenguajes de Especificación (v.gr. de sanners/parsers como lex/YACC), Lenguajes de Documentación de Procesos (como XPDL y JPDL), y Lenguajes para la Prueba (como LoadRunner y Selenium), entre otros. Desarrollar lenguajes propietarios de propósito particular para estas áreas también puede incrementar significativamente nuestra productividad.

Los LCs (y los LPs en particular) se desarrollan a lo largo de un proceso de sistematización–formalización–automatización durante el cual se va conociendo mejor el área para la cual se diseña el lenguaje (el “Application Domain” o “Dominio de Aplicación”), detectando patrones útiles y repetidos en la construcción de programas.

Profundizamos en los Lenguajes de Programación (LPs):

Cuando los LPs son de propósito general (general purpose languages) tienen constructos que son comunes a muchos otros LPs, tales como mecanismos de secuenciación, alternación y repetición de instrucciones, definidos en el marco de lo que llamamos un Sistema de Control (Control System); y mecanismos para construir, combinar, comparar, y descomponer tipos, definidos en el marco de un Sistema de Tipos (Type System). Cuando los LPs son de propósito particular (special purpose languages) tienen además una parte diseñada especialmente para abordar más efectivamente problemas del Dominio de Aplicación, como tipos de datos y estructuras de control ad hoc (v.gr. si el dominio fuera la Matemática, el LP podría tener construcciones y operaciones nativas sobre matrices, entre otras cosas).

El Sistema de Control

La estructura del Sistema de Control está fuertemente influenciada por el paradigma del LP (ver más adelante), pero podemos hablar en general de constructos (o “abstracciones”) como los descritos en la siguiente tabla.

Abstracciones de Control

Primitivas

Compuestas

De Unidad

Instrucciones simples como:

goto’s,
return’s,
Asignaciones
Llamadas a subrutinas o macros

Instrucciones definidas en términos de otras instrucciones, en particular para construir…

Altenaciones: if’s, switch’s
Repeticiones: while’s, for’s
Secuenciaciones: listas de instrucciones eventualmente enmarcadas con begin – end
Bloques de instrucciones abstraídos en forma de subrutinas (procedimientos, funciones, módulos, etc.) o clases

Mecanismos para almacenar, en archivos distintos y utilizando mecanismos como include’s, uses’, y sees’, segmentos de código con instrucciones relacionadas entre sí (“librerías”, clases o Abstract Data Types )

El Sistema de Tipos

La estructura del Sistema de Tipos también está influenciada por el paradigma del LP, pero podemos igualmente hablar en general de constructos como los descritos en la siguiente tabla.

Abstracciones de Datos

Primitivas

Compuestas

De Unidad

Tipos de datos básicos (y predefinidos) como:

Ordinales: char, int, boolean, enumerated
Continuos: real (con distintas precisiones)
Apuntadores
“Tipo nulo” o “comodín” (como el void de C)
Rangos
Archivos

Tipos de datos definidos en términos de otros tipos utilizando Constructores de Tipos como:

Registros (“clásicos” o variables)
Conjuntos
Secuencias (v.gr. arreglos y strings)
Tipos no lineales (v.gr. listas, árboles y grafos)
Clases

Mecanismos para almacenar, en archivos distintos, segmentos de código con declaraciones/ definiciones de datos y de tipos de datos relacionados entre sí (incluyendo librerías, clases y Abstract Data Types) utilizando mecanismos como include’s, uses’, y sees’

El diseño del Sistema de Tipos es una actividad en sí misma por su complejidad y relevancia (define elementos vitales de la semántica del lenguaje). Su definición incluye cuestiones muy importantes como las siguientes:

Chequeo de tipos: Distinguimos entre strongly-typed y weakly-typed languages, dependiendo respectivamente de la menor o mayor tolerancia a que a las variables de un programa no se les haya asociado explícitamente un tipo de dato. Si el chequeo de esta asociación se realiza en tiempo de compilación hablamos de statically-checked languages; si ocurre en tiempo de ejecución hablamos de dynamically-checked languages.
Equivalencia de tipos: Se definen criterios para determinar cuándo se considera que dos variables tienen el mismo tipo, aunque eventualmente hayan sido declaradas de manera distinta. Algunas alternativas son:

Declaration Equivalence: Dos variables tienen tipos equivalentes cuando remiten a la misma declaración de tipo.
Name Equivalence: Dos variables tienen tipos equivalentes si fueron declaradas usando el mismo nombre de tipo en el mismo ámbito (scope).
Structural Equivalence: Dos variables tienen tipos equivalentes si fueron definidas partiendo de los mismos tipos básicos y utilizando los mismos constructores de tipos.

Conversión de tipos: Para combinar variables de varios tipos se aplican mecanismos como los siguientes:

Conversión implícita (promotion), como cuando una variable entera es convertida automáticamente a real por aparecer en una expresión real.
Conversión explícita (casting): la que realiza el programador ya sea mediante la utilización de funciones predefinidas, o utilizando facilidades del lenguaje para “asignar tipos”, como el conocido casting.
Generalización del tipo de una variable a un tipo genérico, como el void del lenguaje C.

Inferencia de Tipos: Permite deducir el tipo adecuado de v.gr. una subexpresión dentro de una expresión; es particularmente importante en los weakly-typed languages. El conocido mecanismo de Unificación presente en ProLog es un interesante ejemplo de inferencia de tipos.

Enunciamos los siguientes Criterios de Clasificación de LPs y abundamos en los 2 últimos, mostrados en la figura de abajo.

Una manera de ganar perspectiva es mediante una clasificación, pero una taxonomía presupone criterios bajo los cuales clasificar. Para los LP podríamos tomar alguno(s) de los siguientes:

Su aspecto ante el programador, lo que permite v.gr. distinguir entre lenguajes visuales y textuales.
Su “composición estructural” (y la complejidad de procesar cada lenguaje), lo cual es el origen de jerarquías como la Jerarquía de Lenguajes de Chomsky.
El “marco conceptual” detrás de los programas que se escriben en un lenguaje particular, lo que facilita la clasificación en Paradigmas de LPs.
El “origen cronológico” en el que fueron creados, lo que da pie al concepto de Generaciones de LPs.

También hablamos de Criterios de Diseño para desarrollar LPs que pueden aplicarse también a LCs:

Simplicidad, que facilita su aprendizaje y uso.
Legibilidad, que permite a un novato entender programas rápidamente.
Expresividad, que permite expresar procesos y estructuras complejos con poco código.
Uniformidad, que brinda consistencia en apariencia y comportamiento de constructos.
Generalidad, que permite combinar constructos estrechamente relacionados en uno más general.
Ortogonalidad, que permite combinar constructos cuando haga sentido, pero lo impide cuando causarían comportamientos inadecuados.
Extensibilidad, que permite añadir nuevos constructos.

Ejemplo Integrador

Ahora abordaremos nuestro ejemplo, en el que incorporaremos mucho de lo que hemos visto hasta ahora en nuestra columna. El ejemplo tiene que ver con Métodos Formales, Lenguajes y Compiladores.

Métodos Formales

En términos generales, los Métodos Formales (MF) son una tecnología mediante la cual podemos:

Escribir una especificación del sistema a desarrollar utilizando un lenguaje formal L1 (usualmente un lenguaje de especificación altamente expresivo), que luego es verificada con intervención humana y procesada mediante un compilador C1 para así generar el código en otro lenguaje formal L2 que representa un diseño de alto nivel.
Tomar este diseño (quizás escrito en un Lenguaje de Arquitectura), verificarlo con intervención humana y procesarlo mediante un compilador C2 que genera el código en otro lenguaje formal L3 que representa un programa susceptible de ser optimizado.
Este programa (escrito quizás en un lenguaje de programación procedural de alto nivel) se procesa mediante un compilador C3 (que eventualmente optimiza el programa) para obtener finalmente el código objeto (quizás en lenguaje máquina).

Las verificaciones mencionadas suelen ser demostraciones matemáticas de que el código correspondiente muestra ciertas propiedades.

En realidad, podríamos pensar que en el desarrollo de software siempre utilizamos algún tipo de MF, pues finalmente se escribe el sistema en algún lenguaje Lx que es procesado por un compilador Cx, el cual usualmente genera código ejecutable. Sin embargo, esta transformación suele realizarse solamente para el tercer numeral de los arriba descritos (la generación del sistema ejecutable a partir del programa escrito en un lenguaje de programación), no para todo el ciclo de desarrollo Requerimientos-Diseño-Programación, como buscan hacerlo los MFs.

Por otro lado, y como ya hemos comentado, los analizadores sintácticos (o “parsers”) suelen definirse mediante una gramática. Para ello se utiliza alguna nomenclatura especializada como BNF o Grafos de Sintaxis; aquí utilizaremos esta última como lenguaje de diseño de lenguajes.

Grafos de Sintaxis

Los Grafos de Sintaxis (GSs) tienen una definición formal inductiva que suele resultar muy intuitiva:

Los siguientes son GSs básicos:

(el grafo nulo)
donde t es un Símbolo Terminal
donde N es un Símbolo no-Terminal

Si son GSs, entonces también lo son los siguientes:

la secuenciación de GSs

la alternación de GSs

la repetición de GSs

Además, consideraremos que a un GS se le puede asignar un nombre con el que luego puede ser referenciado: .

Como ya hemos dicho, con los GSs pueden especificarse los Lenguajes Libres de Contexto. Ahora bien, dentro de esa clase hay un tipo de lenguajes (los descendentes predictivos) para los cuales es relativamente fácil escribir parsers que los procesen, pero las gramáticas que los definen deben presentar ciertas características, en particular las siguientes (que por razones de espacio, no describiremos aquí de manera formal):

La definición de la gramática no puede tener recursión izquierda (el procesamiento se ciclaría indefinidamente), sea directa o indirecta;
En una alternación de grafos, no puede ocurrir que un par de ellos comience con la misma cadena (se requeriría backtracking).

Un pequeño Método Formal

Las reglas para construir un parser descendente predictivo son relativamente sencillas y pueden ser automatizadas como bosquejamos a continuación, utilizando la rutina recursiva C() que recibe como parámetro un GS y genera su código asociado (aquí en Pseudocódigo).

En el código de estas reglas, err_msg() es una rutina que solo imprime un mensaje de error (sintáctico) y eventualmente hace abortar el proceso de análisis sintáctico (pero es posible sofisticarla sistemáticamente para que sea el elemento central de un mecanismo de Recuperación de Errores, de manera que detecte y anuncie errores sin interrumpir ese análisis).

Por otro lado, start() es una rutina recursiva que, dado un GS, regresa el conjunto de símbolos terminales con los que puede iniciar ese GS. Defiendo esa rutina de manera semi-formal (por cuestiones de espacio), y obviando algunas precisiones (como si un GS es nulo), tenemos que:

El start de un GS que es un símbolo terminal es el conjunto con ese no-terminal como único elemento.
El start de un GS que es un símbolo no-terminal es el start del GS que lo define.
El start de un GS que es una secuenciación de GSs es el start del primero de esos GSs.
El start de un GS que es una alternación de GSs es la unión de los start de cada uno de esos GSs.
El start de un GS que es una repetición de GSs es el start del primero de esos GSs.

Las reglas para la generación de parsers a partir de GSs son las siguientes:

	El código asociado a un GS con nombre es una rutina con ese nombre, que incluye el código del GS.
	El código asociado a un GS nulo es la instrucción nula.
	El código asociado a un GS que es un no-terminal es una llamada a la rutina asociada a ese no-terminal.
	El código asociado a un GS que es un terminal es: si el token actual es el que se espera, se invoca al analizador léxico (scanner) para obtener el siguiente token; en caso contrario, se emite un mensaje de error .
	El código asociado a un GS que es una secuenciación de GSs es la secuenciación del código generado para cada uno de los GSs.
		El código asociado a un GS que es una alternación de GSs es la alternación del código de cada GS expresada en términos del token actual y de aquello con lo que puede iniciar cada uno de los GSs respectivos.
		El código asociado a un GS que es una repetición de GSs es el código del primer GS, seguido de la repetición del segundo y del primero hasta que el token no sea algo con lo que puede iniciar el segundo.

Con los elementos anteriores podríamos tener un pequeño MF para los últimos 2 numerales listados en la definición de MF:

Escribiríamos el diseño del lenguaje utilizando el lenguaje formal de los GS, el cual sería verificado por un compilador de GS para detectar recursión izquierda y/o alternaciones de GS no permitidas (además de otras cosas como no-Terminales indefinidos o caracteres inválidos); en caso de haberlas, el diseño sería corregido con intervención humana. Una vez corregido y verificado nuevamente, el compilador de GS podría generar el parser en pseudocódigo como lenguaje intermedio.
Este parser “correcto” a su vez sería procesado (y optimizado, fase que no abordaremos aquí) mediante un compilador de pseudocódigo que generaría el programa en algún lenguaje de alto nivel, a elección del usuario (v.gr. Java, ADA o LISP), para luego ser procesado por el compilador correspondiente que generaría el código ejecutable.

Ejemplo

Las expresiones en los lenguajes de computación son muy importantes. En lenguajes de programación de alto nivel procedurales aparecen en asignaciones, en condiciones de instrucciones como if y while, y en el paso de parámetros; en LISP –el lenguaje funcional por antonomasia– tanto datos como programas son un tipo especial expresiones.

Apliquemos nuestro MF para desarrollar un parser que procese expresiones algebraicas simples como a+3*2, (a+b)*2 ó ((a+b) /3*(b-c)) , en las que la precedencia de los operadores es la usual: + y - tienen igual precedencia, la cual es inferior a la de * y / , que también tienen la misma precedencia.

Uno podría iniciar definiendo la siguiente gramática:

Sin embargo, esa gramática presenta inconvenientes importantes: no garantiza que para cada “(“ haya un “)”, y todos los operadores tienen la misma precedencia. Desgraciadamente, nuestro pequeño MF no podría ayudarnos con estos problemas.

Buscando resolver los problemas anteriores, y generalizando para que en lugar del “Elm" de la gramática anterior, tengamos Identificadores y Números podríamos proponer esta otra gramática:

Esta gramática también presenta inconvenientes, pero esta vez nuestro MF sí puede ayudarnos: nos diría que el no-terminal “Opr" no está definido (el grafo que le correspondía está tiene el nombre “Oprr”), y –más grave aún para efectos del funcionamiento del parser– que existe recursión izquierda (“Xpn").

Podríamos entonces proponer la siguiente gramática:

Pero el MF nos diría que dos de las alternativas en el GS “Xpn” comienzan con la misma cadena (“Opnd”).

Por ello podríamos proponer la siguiente gramática, que es una buena alternativa:

El MF no se quejaría, pues en particular no hay recursión izquierda, no existen dos subgrafos que comiencen con la misma cadena, y no hay no-terminales indefinidos. Y, dado que los operadores aparecen en una jerarquía de grafos, se tienen las precedencias deseadas. Además, los operadores presentan la precedencia deseada.

Con esta gramática que tiene las características que requiere el MF, éste podría proceder a generar el pseudocódigo del parser aplicando la rutina C():

Para “Xpn” el código se iría generando sistemáticamente como se muestra a continuación (el resultado de los start se muestran explícitamente):

Para “Sum” el código que finalmente se generaría sería el siguiente (podrán apreciar varias oportunidades de optimización):

Para “Fact” el código que finalmente se generaría sería el siguiente (también con varias oportunidades de optimización):

Por definición, el programa principal del parser llamaría a la rutina Xpn() (dado que es el símbolo no-terminal que actúa como símbolo inicial de la gramática), la cual llamaría a Sum() cuando fuera necesario y ésta de igual manera a Fact(). Ustedes podrán constatar que ese programa procesa el tipo de expresiones que definimos.

Conclusiones

Utilizando este MF para desarrollar parsers podemos destinar más tiempo al diseño de una gramática que procese el lenguaje que nos interesa, que a la escritura de un programa que lo haga con lo cual podemos desarrollar un lenguaje de mejor calidad; y al no ser necesario atender tantos detalles, habría menos probabilidad de cometer errores (el parser también podría tener mejor calidad), y terminaríamos más rápidamente (la productividad se incrementaría). Además, los GSs son más expresivos, simples y legibles que el pseudocódigo, con lo cual ganaríamos una mejor “mantenibilidad”.

Lo anterior es posible porque se introduce un lenguaje formal de mayor nivel de abstracción (GS), que nos permite no tener que atender detalles poco importantes (como instrucciones en y con if’s, while’s, switch’s, conjuntos, recursiones, etc.) para desarrollar software de una manera más abstracta y sistemática.

Si medimos el “tamaño” de del input (cantidad de GSs) y del output (cantidad de líneas de pseudocódigo) de la subrutina C(), podríamos ver que en general, cuando crece la complejidad del input, la complejidad del output puede crecer en un orden de magnitud (10x). Esto es: cuando usamos el MF para desarrollar el parser asociado a una gramática definida con GSs que contienen muchas alternaciones y repeticiones de GSs, la proporción entre el input (GSs) y el output (líneas de pseudocódigo) puede exceder las 10 veces (1,000%).

Y esa es precisamente la idea detrás del desarrollo de lenguajes propietarios: introducir un lenguaje formal que nos permita subir el nivel de abstracción de lo que hacemos para centrarnos más en actividades como el diseño, y dejar que el compilador del lenguaje propietario genere los detalles (como ocurrió con los lenguajes de alto nivel, que generaban el código en lenguaje máquina asociado a constructos como if’s, while’s).

Hacer esto es particularmente relevante en un mundo en el que actualmente en muchas grandes transnacionales tecnológicas, “Robots” realizan funciones como las anteriores y generan la misma cantidad de código (en lenguajes de alto nivel) que el que generan sus ingenieros.

Bio

Luis Vinicio León Carrillo es Director General y co-fundador de e-Quallity. Antes de fundar e-Quallity fue profesor-investigador en la universidad jesuita ITESO durante varios lustros, que incluyeron una estancia de posgrado en Alemania, durante la cual abordó aspectos relacionados con el Testing y los formal methods and languages.

Cómputo Cuántico

Ivett Sanchez — Tue, 15 Jan 2019 19:30:25 +0000

Cómputo Cuántico

Ivett Sanchez Tue, 01/15/2019 - 13:30

Publicado en

SG #58

Autor

Pedro Galván

#YoConfieso que al escuchar sobre cómputo cuántico, una parte de mi se emociona por todas las posibilidades que abre, pero otra parte quiere taparse los oídos y “hacerse loco” para no tener que lidiar con la complejidad y nuevos retos que involucra un nuevo paradigma de cómputo. Pero eventualmente, el futuro nos alcanza y tenemos que enfrentarlo, así que aprovechemos esta oportunidad para conocer más sobre este tema.

Básicamente, la mecánica cuántica plantea que los electrones u otras partículas subatómicas tienen algunos superpoderes medio locos como la superposición que es la posibilidad de ser una onda y partícula a la vez, el efecto túnel (quantum tunneling) que les permite atravesar barreras, y el entrelazamiento (entanglement) que les da poderes psíquicos —como si tuvieran un gemelo y cuando uno es afectado el otro también de forma simultánea.

Una computadora cuántica aprovecha estos fenómenos cuánticos para computar problemas matemáticos complejos que tomaría mucho tiempo/esfuerzo resolver por medio de una computadora tradicional.

Una computadora cuántica utiliza qubits para representar información a través de un sistema. A diferencia de un bit tradicional, cuyo estado es representado por un 0 o un 1, el estado de un qubit es una superposición de ambos valores (0 y 1). Es decir que un qubit puede tener distintos estados al mismo tiempo.

Imaginemos que escribo una ‘X’ en una página aleatoria de un libro aleatorio en una biblioteca con un millón de libros y le pido tanto a una computadora clásica como a una cuántica que encuentren la X. Para resolver esto, la computadora clásica tendrá que recorrer una por una cada una de las páginas de cada uno de los libros en la biblioteca, lo cual requiere una gran cantidad de tiempo. En cambio, la computadora cuántica utiliza la superposición y entrelazamiento de sus qubits para analizar todas las páginas al mismo tiempo. Repasemos esto:

El estado de un qubit es una superposición de 0 y 1.
Un sistema complejo de qubits puede estar en múltiples superposiciones de forma simultánea, por ejemplo 5 qubits pueden estar en una superposición de 32 estados (2^n).
Si tenemos 2 qubits entrelazados, la información de un qubit revelará información sobre el otro qubit.

Al combinar las capacidades de superposición y entrelazado, los qubits pueden procesar cantidades de datos enormes de forma simultánea y resolver problemas complejos que le tomarían millones de años a las computadoras clásicas.

Las computadoras cuánticas ya son una realidad. Por el momento solo existen en laboratorios sofisticados, y operan con unos cuantos qubits, pero ya sabemos cómo se mueve nuestra industria, y antes de que nos demos cuenta ya se estarán utilizando para todo tipo de fines. En las próximas páginas conoceremos más sobre ellas y sus aplicaciones. Dado que este es un tema con mucha tela de donde cortar, te invito a que consultes las referencias indicadas en los distintos artículos para conocer más al respecto.

Bio

Pedro Galván Kondo es Director Editorial de SG Software Guru.

Cuando el Futuro nos Alcance: ¿En qué podemos utilizar computadoras cuánticas?

Ivett Sanchez — Tue, 15 Jan 2019 19:29:13 +0000

Cuando el Futuro nos Alcance: ¿En qué podemos utilizar computadoras cuánticas?

Ivett Sanchez Tue, 01/15/2019 - 13:29

Publicado en

SG #58

Autor

¿Cuándo tendremos una computadora cuántica lista para usarse? En los albores del siglo XXI, las respuestas a esta pregunta eran una oda a la incertidumbre: desde la negación total de cualquier posibilidad de éxito hasta el optimismo de quienes esperábamos verlas antes de llegar a la vejez. La realidad resultó ser aún más entusiasta: menos de dos décadas después, tenemos ya computadoras cuánticas funcionales, con muchos temas técnicos por resolver (particularmente en el escalamiento) pero ya las tenemos con nosotros.

Ahora, ¿qué sigue? ¿Cómo hacemos de estos resultados formidables una rama de la industria, fuente de empleo, un nuevo camino para resolver problemas de frontera?

Veamos la historia de la computación para intentar responder las preguntas anteriores. En el siglo XIX y principios del XX, la palabra computer era empleada para referirse a una profesión, no a una máquina: los human computers fueron personas que se dedicaban, bajo contrato, a la realización de cálculos complejos y su trabajo fue una de las primeras aplicaciones de los métodos de producción industrial en el quehacer científico.

Tanto los human computers como, posteriormente, las machine computers trabajaron en problemas de corte científico y militar. Aunque esta labor tuvo impactos mayúsculos en la sociedad, la capacidad instalada y los requerimientos en capital humano no eran suficientes para que la computación fuese un detonador de crecimiento económico. La industria de TICs de nuestros tiempos es el resultado la transversalidad de la tecnología computacional, esto es, de la combinación virtuosa de hardware en constante evolución, capital humano y algoritmos sofisticados en la solución de problemas, emanados de gobiernos así como de la iniciativa privada, de corte ingenieriles, contables, administrativos y financieros, entre muchos otros.

Es muy probable que el cómputo cuántico pase por un proceso similar al ya descrito. En este punto de la historia del cómputo cuántico, necesitamos imaginar y desarrollar killer apps.

En este artículo hablaremos de dos áreas incipientes de aplicaciones del cómputo cuántico: solución de problemas de optimización e internet cuántico.

Solución de problemas de optimización

Los problemas de optimización se caracterizan por tener modelos matemáticos en los que hay una o varias expresiones matemáticas para las que necesitamos encontrar valores máximos o mínimos. Por ejemplo: ¿de qué forma puedo acomodar el inventario para minimizar el espacio no utilizado?, o ¿cuál es la cantidad máxima estimada de energía eléctrica que se consumirá por parte de la industria mexicana en 2027?

Resolver problemas de optimización es, en lo general, una tarea complicada que necesita de expertos en matemáticas, computación y el área de la que emanan dichos problemas. Las disciplinas en las que se usan técnicas de optimización para modelado de problemas son muchas y variadas: aeronáutica, inversiones, comportamiento de casas de bolsa e inteligencia artificial, entre otras. En todos los casos, el modelo consiste en la construcción de funciones de costo (también llamadas funciones objetivo) y la solución del problema consiste en conocer las variables de entrada que minimizan/maximizan el valor de la función.

Los problemas de optimización tienden a consumir muchos recursos computacionales en poco tiempo (esto es, son típicamente problemas NP-duros). Gracias a los fenómenos de superposición, paralelismo cuántico y tunelamiento cuántico, los ordenadores cuánticos son buenos candidatos para resolver problemas de optimización (ver por ejemplo [1] para una introducción a la programación de quantum annealers para la solución de problemas de optimización) y, por ello, una parte de la comunidad de científicos e ingenieros cuánticos nos dedicamos a la construcción de algoritmos cuánticos para resolver problemas en las siguientes áreas, entre otras:

Portafolios de inversión.
Visión computacional.
Simulación de moléculas.
Aprendizaje computacional (machine learning).

Para conocer más de estos temas, recomendamos revisar los contenidos de [1,2,3,4,5]. Además, es conveniente conocer las propuestas y programas de trabajo en materia de algoritmos cuánticos que hoy se encuentran en el mercado global de computación cuántica. Para este propósito, recomendamos visitar los sitios enlistados en [6,7,8,9,10].

Internet cuántico

El término Internet Cuántico es un neologismo cuya definición está en evolución constante. Al momento, esta noción representa el uso de protocolos de seguridad emanados de la teoría de la información cuántica así como la construcción de redes para comunicación de datos cuánticos.

En cierto sentido, las computadoras cuánticas actuales son como los mainframes: grandes, con altos costos de operación y, además, no es fácil cambiarlos de lugar. Por lo anterior, el acceso a estas máquinas se hace de forma remota y es muy probable que este método de acceso permanezca así por varios años.

En este escenario, es importante construir protocolos de acceso seguro a las computadoras cuánticas que estén disponibles en la nube, protocolos que puedan echar mano de métodos de codificación de datos como el protocolo de distribución cuántica de llaves BB84 ([11,12]).

Por otra parte, la creación de sensores capaces de detectar y transmitir información cuántica, área de rápido crecimiento que es abordada en el artículo de Marco Lanzagorta escrito para esta edición especial, requiere de redes de comunicación para ser funcionales y útiles para la sociedad.

La creación del Internet Cuántico demanda la elaboración de tecnología cuántica como repetidores cuánticos e implantaciones robustas del protocolo de teletransportación cuántica. Como en toda aventura científico-tecnológica, es muy probable que los desarrollos de hoy encuentren usos y vías de crecimiento ulterior que hoy no podemos vislumbrar. Por lo anterior, esta etapa del cómputo cuántico es tierra fértil para mentes y organizaciones emprendedoras.

Referencias

[1] S.E. Venegas-Andraca, W. Cruz-Santos, C. McGeogh and M. Lanzagorta. A cross-disciplinary introduction to quantum annealing-based algorithms. Contemporary Physics 59(02), pp. 174--196 (2018).

[2] R. Biswas et al. A NASA perspective on quantum computing. Parallel Computing

64(C), pp. 81-98 (2017).

[3] M. Schuld et al. Contemporary Physics 56:2, pp. 172-185 (2015)

[4] J. Biamonte et al. Nature 549, pp. 195-202 (2017).

[5] A. Aspuru-Guzik, R. Lindh, and M. Reiher. The Matter Simulation (R)evolution. American Chemical Society Cent. Sci. 4(2), pp. 144-152 (2018).

[6] IBM Q Experience. https://quantumexperience.ng.bluemix.net

[7] D-Wave Systems: Quantum Computing. https://www.dwavesys.com/quantum-computing

[8] Rigetti Computing. https://rigetti.com

[9] Microsoft Quantum. https://www.microsoft.com/en-us/quantum

[10] Google AI Quantum. https://ai.google/research/teams/applied-science/quantum-ai

Bio

Arturo Silva Ordaz (arturo.silva@quantumworks.io) es Ingeniero Físico por el Tecnológico de Monterrey, estudiante del doctorado en Ciencias de la Ingeniería por la misma institución y director general de la empresa Quantum Works.

Salvador E. Venegas Andraca (salvador.venegas-andraca@keble.oxon.org) es profesor-investigador y director del grupo de investigación en Procesamiento Cuántico de la Información en el Tecnológico de Monterrey. Es pionero del cómputo cuántico en México y del procesamiento cuántico de imágenes. Desde 1993, es consultor y conferencista para la iniciativa privada y los tres niveles de gobierno en temas de computación cuántica, inteligencia artificial, transferencia de tecnología, sistemas electrónicos, tecnología computacional y propiedad intelectual.

Desarrollo y Simulación de Algoritmos Basados en Temple Cuántico

Ivett Sanchez — Tue, 15 Jan 2019 19:28:30 +0000

Desarrollo y Simulación de Algoritmos Basados en Temple Cuántico

Ivett Sanchez Tue, 01/15/2019 - 13:28

Publicado en

SG #58

Autor

William de la Cruz de los Santos

El algoritmo de Temple Cuántico (TC) —en inglés, quantum annealing— es uno de los paradigmas del cómputo cuántico que más aplicaciones ha encontrado desde el plegado de proteínas, lógica matemática, visión por computadoras, entre otras [1,2]. El TC se basa en las propiedades de la mecánica cuántica y hace uso del fenómeno físico de túnel cuántico para explorar el espacio de soluciones de un problema de optimización combinatorio [3].

Uno de los líderes en tecnología cuántica que han aprovechado el algoritmo de TC es la empresa canadiense D-Wave Systems [4], cuyas computadoras cuánticas actualmente son utilizadas por distintos laboratorios de alto perfil para abordar aplicaciones y estudios teóricos en áreas como: machine learning, exploración espacial, optimización combinatoria, biología, teoría de gráficas, entre otras.

Los avances teóricos se han centrado en estudiar el comportamiento de la evolución del algoritmo de TC para acelerar el proceso de búsqueda de soluciones. Mientras que los avances experimentales y de aplicación se han enfocado en determinar cuáles problemas son más susceptibles de ser resueltos usando TC dadas las limitaciones de hardware cuántico actual.

Recordemos que la unidad de procesamiento más pequeña en una computadora cuántica es el qubit. Un qubit, a diferencia de su contraparte clásica el bit, puede estar tanto en 0/1 como en una superposición entre ambos valores. En el caso del hardware cuántico de D-Wave, los qubits se encuentran interconectados en la llamada topología Chimera. La Figura 1 muestra la topología del procesador D-Wave One el cual tiene 128 qubits. En esta topología, para cualquier qubit q se le asocia un coeficiente h(q) que representa la magnitud de un campo magnético transversal y para cualquier pareja de qubits q1 y q2, se les asocia un coeficiente J(q1,q2) que representa la fuerza de acoplamiento entre q1 y q2. De esta manera, la programación de un procesador cuántico de D-Wave consiste en configurar los coeficientes h(q) y J(q1,q2) para cada qubit q y todas las parejas de qubits q1 y q2, respectivamente.

Figura 1. Topologia del procesador cuantico D-Wave One.

Una vez configurados los coeficientes h(q) y J(q1,q2), se lleva a cabo el proceso del algoritmo de TC, el cual hace evolucionar los estados de los qubits. Finalmente, se lleva a cabo una medición cuántica la cual hace que los estados de los qubits “colapsen” a estados clásicos 0/1. El argumento principal del TC es que si el tiempo de evolución del sistema cuántico es lo suficientemente largo, la energía final del sistema será la más baja, y la configuración final de los qubits representa una solución a un problema. La energía del sistema es la suma de los términos q*h(q) y q1*q2*J(q1,q2) para todos los qubits q y todas las parejas q1 y q2. Los tiempos de evolución que se pueden establecer en el hardware cuántico están entre 10 y 100 microsegundos. Dado que el proceso de medición cuántica es un evento probabilístico, se tienen que realizar varias ejecuciones del algoritmo TC con las mismas condiciones iniciales, y el resultado final se toma por votación.

Consideremos cada una de las etapas en la solución de un problema de optimización usando el algoritmo de TC:

Un problema de interés en teoría de gráficas es el Máximo Conjunto Independiente (MCI). Una gráfica es una pareja G=(V,E) donde V={1,2,...,n} es un conjunto de vértices y E={e1,e2,...,em} es un conjunto de aristas o parejas de vértices (ver figura 2). Un subconjunto A contenido en V es independiente si para todo par de vértices i,j en A, la pareja {i,j} no forma una arista en E. Así, dada un grafica G=(V,E), el problema MCI consiste en encontrar el conjunto independiente A más grande en G.
Para representar de manera lógica el problema MCI asociamos variables booleanas xj a los vértices j tal que j (no) pertenece al conjunto A si xj = 1 (0) para j=1,...,n. Así, por cada posible combinación de valores para x1,...,xn se le asocia un conjunto A que consiste de los vértices j para los cuales xj=1 con j=1,...,n. La cardinalidad del conjunto A coincide con la suma x1 +...+ xn y A es independiente si se cumple que para toda arista {i,j} en E, el producto xi*xj = 0. De este modo, el problema MCI se puede ver como la minimización de una función de energía E(x1,...,xn) como se muestra en la Figura 2.
El hardware cuántico D-Wave se diseñó con el objetivo de minimizar funciones de la forma E(x1,...,xn) con términos lineales y por pares. La representación cuántica de la función E(x1,...,xn) consiste en encontrar una correspondencia entre los términos por pares con una o más parejas de qubits en la topología Chimera. La Figura 2 muestra una incrustación del problema en la topología Chimera.
Para la ejecución del algoritmo de TC se establece el tiempo de evolución ta y el número de iteraciones que se repetirá el proceso. Por cada iteración se obtiene como resultado un valor de energía y una configuración de los qubits involucrados en la representación del problema. Las soluciones de un algoritmo de TC se interpretan dependiendo del objetivo, ya sea obtener la mínima energía de la función E(x1,...,xn) o encontrar una configuración de los qubits tal que satisfagan una propiedad específica. Por ejemplo, para el ejemplo de la Figura 2, la mínima energía es de 4 y el número de veces que aparece es 781 de 1000 iteraciones. Por lo que la probabilidad de éxito del algoritmo es p=781/1000.

Figura 2. Etapas para la solución de problemas usando el algoritmo de TC.

Estas tecnologías cuánticas han propiciado un nicho de oportunidades en la investigación científica básica. Por ejemplo, algunas de las problemáticas en cada una de las etapas son las siguientes: (1) determinar a qué clase de problemas se pueden encontrar ventajas en la solución de problemas en comparación con los mejores algoritmos clásicos conocidos; (2) encontrar para cada problema de interés la mejor representación matemática con el menor número de variables lógicas; (3) obtener la representación física sobre la topología del hardware cuántico que requiera el menor número de recursos físicos; y (4) amplificar la probabilidad de éxito para encontrar soluciones a un problema dado usando el menor número de repeticiones.

Referencias

[1] Salvador E. Venegas-Andraca, William Cruz-Santos, Catherine McGeoch & Marco Lanzagorta, A cross-disciplinary introduction to quantum annealing-based algorithms, Contemporary Physics, Vol. 59(2), pp. 174—197 (2018).

[2] William Cruz-Santos, Salvador E. Venegas-Andraca & Marco Lanzagorta, A QUBO formulation of the stereo matching problem for D-Wave quantum annealers, Entropy, Vol. 20(10), pp. 786 (2018).

[3] Tadashi Kadowaki & Hidetoshi Nishimori, Quantum annealing in the transverse Ising model, Physical Review E, Vol. 58(5), pp. 5355—5363 (1998).

[4] https://www.dwavesys.com

[5] Rupak Biswas et al., A NASA perspective on quantum computing: opportunities and challenges, arXiv:1704.04836v1 (2017).

[6] Thomas E. Potok et al., A Study of Complex Deep Learning Networks on High Performance, Neuromorphic, and Quantum Computers, arXiv:1703.05364v2 (2017).

Bio

El Dr William De la Cruz es profesor investigador en la Universidad Autónoma del Estado de México. Los intereses del Dr. De la Cruz son el desarrollo de algoritmos cuánticos para problemas NP-difíciles, óptica aplicada y visión por computadoras.

Procesamiento Cuántico para Redes de Sensores

Ivett Sanchez — Tue, 15 Jan 2019 19:27:32 +0000

Procesamiento Cuántico para Redes de Sensores

Ivett Sanchez Tue, 01/15/2019 - 13:27

Publicado en

SG #58

Autor

Marco Lanzagorta

Uno de los mayores esfuerzos científicos en años recientes ha sido el control y manejo de fenómenos cuánticos para mejorar el desempeño de sistemas de comunicación y procesamiento de información. Más aún, el desarrollo de otros productos tecnológicos cuánticos como sensores y redes permite pensar en la construcción de sistemas robustos y con amplias capacidades, por ejemplo, la instalación de redes de sensores cuánticos y/o clásicos que transmitan información a computadoras cuánticas para la evaluación de escenarios complejos.

Los sensores que componen una red no necesariamente tienen que ser idénticos, en general puede ser un conjunto heterogéneo de aparatos de detección (por ejemplo, sensores acústicos, hidrológicos, ópticos, gravitacionales, y electromagnéticos son necesarios para establecer sin ambigüedad la presencia de un submarino o el lanzamiento de un misil). En la práctica, cada sensor lleva a cabo y reporta mediciones a muy alta frecuencia (~1,000 reportes por segundo).

Consideremos un simple ejemplo: si tenemos N objetivos y M sensores en un tiempo de detección de 45 minutos (el tiempo aproximado de vuelo de un misil proveniente de Asia a los Estados Unidos), a una frecuencia de 1,000 reportes por segundo, el resultado es 45x103xMxNx60 datos con una incertidumbre 4-dimensional (tres espaciales y una temporal) diferente de cero. Cuando N=10 y M=20, estamos hablando de 5x107 datos. El problema de detección y seguimiento del misil se reduce a determinar el valor de N y encontrar las N trayectorias geométricas que óptimamente unen los cuerpos geométricos que describen la incertidumbre en cuatro dimensiones de cada una de las 5x107 mediciones (por lo general, un conjunto de elipsoides no alineadas) y satisfacen las leyes dinámicas del movimiento del blanco (en este caso, del movimiento parabólico en un campo gravitacional). Claramente, este es un problema computacional muy complejo.

Las redes de sensores ofrecen un mejor desempeño a través del uso de algoritmos de fusión de datos que combinan la información de los nodos de la red para proveer información óptima del objetivo. De esta forma, el resultado producido por un algoritmo de fusión de datos es la información más exacta, completa, oportuna, y confiable que se tiene del objetivo.

La fusión de datos y la computación cuántica son áreas muy activas de investigación científica y tecnológica. Sin embargo, al momento de escribir este artículo, no ha existido mucha interacción entre estas áreas científicas. Empero, es una idea natural el tratar de combinar estas dos áreas de investigación. De esta forma emerge el área de la “Fusión Cuántica de Datos” cuyo objetivo es el desarrollo de técnicas computacionales para su implantación en computadoras cuánticas, con el propósito de procesar información proveniente de redes heterogéneas de sensores. En este artículo describimos una taxonomía para clasificar las técnicas que se podrían utilizar para la fusión cuántica de datos.

En general, uno necesitaría determinar: (1) cuál es la mejor combinación de sensores clásicos y cuánticos para obtener la información requerida del objeto de estudio; y (2) cómo asociar y fusionar la información no-lineal de sensores clásicos y cuánticos de tal manera que reduzcan las incertidumbres en las variables bajo análisis.

Con esto en mente podemos identificar las cuatro técnicas posibles para llevar a cabo la fusión de datos provenientes de redes de sensores heterogéneas. Y a su vez, estas técnicas caracterizan cada uno de los grupos taxonómicos que clasifican la fusión cuántica de datos.

La primer técnica y más básica es el uso de técnicas tradicionales clásicas de fusión de datos aplicadas a la información clásica obtenida por la red de sensores. En el caso de sensores cuánticos, esto implica realizar la medición de los qubits que describen el estado del sensor para obtener bits clásicos que puedan ser combinados con los bits producidos por los sensores clásicos. Podemos llamar esta técnica Fusión Tradicional de Datos (ver figura 1).

Figura 1. Fusión tradicional de datos

Ya comentamos que la mayoría de los algoritmos para la fusión tradicional de datos requieren vastos recursos computacionales para procesar grandes cantidades de información. Así que la siguiente técnica, a la que podríamos llamar Fusión Cuántica de Datos (figura 2), consistiría en utilizar una computadora cuántica para acelerar el proceso clásico de fusión de información. Por ejemplo, en el US Naval Research Laboratory (NRL) hemos desarrollado algoritmos cuánticos para la fusión de datos aplicada a la información clásica proveniente de una red de sensores heterogéneos aplicada a la defensa de misiles y al seguimiento de objetivos subacuáticos con sonar pasivo. Resultados teóricos y de simulación muestran que estos algoritmos cuánticos ofrecen una ventaja cuadrática en el número de pasos computacionales para la detección y seguimiento óptimos de un número masivo de blancos de geometría arbitraria.

Figura 2. Fusión cuántica de datos

Recordemos que los sensores cuánticos son dispositivos que usan algún fenómeno cuántico para que, bajo ciertas circunstancias, se incremente su exactitud, resolución, y sensibilidad en comparación a sus contrapartes clásicas. El problema es que al medir la información sensada, se “aterriza” esta a bits tradicionales para transmitirla a un centro de procesamiento de información. Es así que podemos diseñar otra técnica de fusión de datos en la que se considere el estado de cada sensor cuántico antes de la medición. Esto es, el estado de cada sensor después del proceso de detección y antes de su medición, estado que es representado por qubits. Estos qubits pueden entonces ser enviados a una computadora cuántica (por ejemplo usando teletransportacion cuántica), y así el estado cuántico final de los sensores estará representado con qubits dentro de una computadora cuántica. De esta forma no se pierde información cuántica en el proceso de medición. Esta técnica puede ser llamada Fusión de Datos Cuánticos (figura 3).

Figura 3. Fusión de datos cuánticos

Si bien las tres técnicas anteriores emergen de forma natural al considerar la intersección entre las redes de sensores y la computación cuántica, la cuarta y última técnica es una idea completamente nueva. En este caso consideremos los qubits que describen el estado de los sensores como si fueran variables cuánticas dinámicas en una computación cuántica. Esto es, en vez de representar el estado final de los sensores después del proceso de detección, los qubits representan el estado intermedio de los sensores que sigue evolucionando debido a su interacción con el medio ambiente. Cada sensor cuántico de la red actúa como qubits lógicos que son parte de una computadora cuántica extendida y que pueden ser operados dinámicamente por el procesador cuántico. De esta forma emerge el concepto de Fusión Extendida de Datos Cuánticos (figura 4). En estos algoritmos, el medio ambiente que transforma el estado de los sensores cuánticos es equivalente a un oráculo computacional. En este modelo, estamos usando el medio ambiente como un recurso computacional.

Figura 4. Fusión extendida de datos cuánticos

En el NRL hemos desarrollado algoritmos de fusión extendida de datos cuánticos para el caso de una red de gravímetros cuánticos. En este caso, uno puede imaginarse un procesador cuántico con este tipo de qubits como si fuera un arreglo de pequeños gravímetros cuánticos muy sensibles cuyo estado puede ser manipulado independientemente usando compuertas cuánticas. Entonces, el campo gravitacional va a afectar el estado del procesador cuántico. Como consecuencia, en principio uno podría determinar las características del campo gravitacional observando su efecto en los qubits del procesador cuántico. En consecuencia, la ejecución de nuestro algoritmo de fusión extendida de datos cuánticos convierte a la computadora cuántica en un gravímetro.

Resultados numéricos de nuestros modelos teóricos muestran que, si uno tuviera acceso a una computadora cuántica universal perfecta con 94 qubits, el gravímetro resultante sería equivalente al mejor gravímetro conocido hoy en día (gravímetro de interferencia atómica). Sin embargo, como recurso de medición, la sensibilidad del gravímetro cuántico crece exponencialmente con el número de qubits. Así, con 100 qubits en una computadora cuántica perfecta uno tendría una sensibilidad teórica 100 veces mayor que el gravímetro de interferencia atómica. Como tal, esta técnica pudiera tener importantes aplicaciones navales como la detección de submarinos y la navegación submarina usando mapas gravitacionales.

De esta forma podemos concluir que las computadoras cuánticas pudieran ser utilizadas para acelerar el proceso de fusión de datos, el cual es un área de tremenda importancia comercial y militar. Más aún, permitiendo la manipulación del entrelazamiento de la red de sensores cuánticos uno podría desarrollar tecnologías realmente revolucionarias para la detección y medición de campos gravitacionales y electromagnéticos de muy baja intensidad.

Bio

El Dr. Marco Lanzagorta es científico adscrito al Laboratorio de Investigaciones de la Marina de los Estados Unidos de América. Antes de esta responsabilidad, el Dr Lanzagorta fue director del Grupo de Tecnologías Cuánticas de ITT Exelis (hoy Harris Corporation) y llevó a cabo actividades de investigación científica en el CERN así como en el International Center for Theoretical Physics.

Criptografía Post-cuántica en Sistemas con Recursos Limitados

Ivett Sanchez — Tue, 15 Jan 2019 19:26:14 +0000

Criptografía Post-cuántica en Sistemas con Recursos Limitados

Ivett Sanchez Tue, 01/15/2019 - 13:26

Publicado en

SG #58

Autor

Las soluciones de tipo “Internet de las cosas” (IoT) cada vez son más comunes tanto en empresas como hogares. Dichas soluciones frecuentemente manejan información sensible, por lo que es deseable que manejen un canal de comunicación cifrado. Sin embargo, así como la tecnología tiende al cambio, la seguridad de la información también está presentando cambios, y el cómputo cuántico presenta una amenaza significativa. Dada su naturaleza, una computadora cuántica puede realizar millones de operaciones en paralelo y fácilmente descifrar información protegida con criptografía tradicional.

Una solución ante este problema es el uso de algoritmos post-cuánticos, capaces de soportar ataques de ordenadores cuánticos. El uso de este tipo de algoritmos ya es relativamente común en el cómputo empresarial y móvil. Sin embargo, las soluciones IoT típicamente utilizan dispositivos con recursos limitados, que no necesariamente cuentan con la capacidad necesaria para ejecutar estas cargas de trabajo.

Ante esto, los autores han realizado una investigación para estudiar la viabilidad y desempeño de algoritmos de criptografía post-cuántica dentro de sistemas con recursos limitados. En este artículo se presenta la evaluación del desempeño de un algoritmo que preserva el servicio de integridad dentro de sistemas con procesadores ARM.

Un poco de historia

Históricamente hablando, la criptografía puede clasificarse en 4 etapas: clásica, moderna, cuántica y post-cuántica. El primer uso reconocido de la criptografía data de hace cerca de 4 mil años, en unos jeroglíficos no estándar encontrados en una tumba egipcia. La criptografía clásica, de una u otra manera continuó usándose conforme la civilización humana continuó su evolución.

La segunda guerra mundial marca un hito importante para la criptografía. Ante la necesidad de proteger los mensajes enviados a las tropas, aviones y submarinos a distancia, se realizaron grandes avances tanto en la construcción de máquinas criptográficas (ej. Enigma) como en el análisis para ingeniería inversa y construcción de máquinas capaces de descifrar dichos mensajes.

La siguiente gran revolución aparece a finales de los años 60 con el desarrollo de la criptografía asimétrica donde se utiliza una llave conocida por el público para cifrar los mensajes y otra llave privada para descifrarlos.

En los años 70’s se tienen las primeras ideas relacionadas con la criptografía cuántica, destacando los algoritmos de Shor y Grover. Sin embargo, fue hasta los 80’s cuando se muestran las primeras publicaciones de nuevos protocolos que basaban su seguridad en los principios de la mecánica cuántica —como el de incertidumbre o el de superposición— utilizando láseres para emitir información en un fotón.

Cuando los algoritmos de la criptografía de llave pública empiezan a verse comprometidos por el cómputo cuántico, surge la criptografía post-cuántica, que hace referencia a los algoritmos diseñados para resistir ataques de computadoras cuánticas. En ella se aprecian varias ramas que se diferencían por la forma en cómo operan, siendo estas: algoritmos basados en rejillas, algoritmos basados en ecuaciones multivariables, algoritmos basados en curvas elípticas isogeneas supersingulares, algoritmos basados en hashes, y algoritmos basados en códigos.

Desde el punto de vista del uso y desempeño de este tipo de algoritmos, se ha explorado su ejecución en sistemas de propósito específico en entornos controlados, como lo son: los FPGA, AVR y ASIC, por mencionar algunos, dejando pendiente un análisis del comportamiento y desempeño en sistemas de recurso limitado, de gama media y baja, como lo son: Raspberry Pi, Beaglebone o Banana Pro con arquitectura ARM. De ahí que los antecedentes relacionados con este trabajo exhiben trabajos con algoritmos post-cuánticos que podrían dividirse en: ejecuciones en dispositivos FPGAs, en dispositivos de uso específico y trabajos de algoritmos post-cuánticos en la arquitectura ARM, los cuales radican en cifrado, firmas digitales y acuerdos de llave, dejando abierta la posibilidad de explorar la primitiva de hash, enfocada al servicio de integridad, así como su comportamiento en sistemas con recursos limitados.

Desempeño de un algoritmo post-cuántico para el servicio de integridad

La función hash SHA-3 es el último miembro de la familia de estándares Secure Hash Algorithm, cuyo propósito es sustituir las aplicaciones actuales de su predecesor SHA-2 en caso de ser necesario, puesto que esta mejora la solidez del algoritmo hash.

La familia de las funciones SHA-3 es capaz de enfrentar ataques realizados por computadoras cuánticas, destacando entre ellos: el uso del algoritmo de Grover, ataques de preimagen, de segunda preimagen y de resistencia a colisiones, así como el ataque de cumpleaños. Esto, dado que la seguridad proporcionada por el algoritmo SHA-3 ante ataques cuánticos recae en las grandes salidas de datos que este genera, puesto que está comprobado matemáticamente que es resistente a la colisión cuántica. Hablando en términos de bits, la seguridad que genera cada una de sus variantes, es del mismo tamaño de bits que la salida, en los ataques a preimagen y 2da preimagen, y a la mitad de los bits en ataques de resistencia a colisiones.

Desde el punto de vista de la codificación, a la fecha se han desarrollado códigos en distintos lenguajes para utilizar las fortalezas que presenta esta familia. De hecho, el proyecto de investigación "Open Quantum Safe", ha puesto al alcance de la comunidad una biblioteca de funciones con dos líneas de trabajo principales. La primera línea consiste en el desarrollo y mantenimiento de liboqs, una biblioteca de código abierto en C que implementa algoritmos criptográficos resistentes a ataques cuánticos. La segunda línea consiste en el prototipado de integraciones en protocolos y aplicaciones comunes, tales como la biblioteca OpenSSL.

Para la investigación descrita en este artículo, se adecuó liboqs para poder usarla en procesadores con arquitectura ARM. Se modificó un constructor para que pudiera hacer uso de la función SHA-3 y de todas las opciones que brinda la biblioteca. El programa diseñado tiene como propósito la obtención de las mediciones en los tiempos de procesamiento. Esto, considerando el tiempo que tardan tanto el embebido como la computadora personal para resolver las operaciones de las funciones hash de la familia de SHA-3.

Ejecución en sistemas con recursos limitados

Para las pruebas de desempeño, se ejecutó cada uno de los miembros de la familia SHA-3 con salidas de 224, 256, 384 y 512 bits. Esto, con la finalidad de obtener una comparativa de los tiempos de procesamiento que se tienen entre el sistema embebido Raspberry Pi 1 modelo B, con un procesador de un solo núcleo, 700 MHz de velocidad y 256 MB de memoria RAM y una arquitectura x64. Además, se observó el desempeño en las funciones de salida variable SHAKE128 y SHAKE256, con salidas de tamaño 512, 1024, 2048, 4096 y 8192 bits, respectivamente. Para finalizar, se comparó el desempeño que mostraba la función hash SHA-3 al ejecutarse en el sistema embebido y las funciones hash antecesoras, SHA-1 y SHA-2.

Sin embargo, el reto presentado al estudiar el desempeño del algoritmo SHA-3 se presentó al querer ejecutarlo en un dispositivo de poder limitado de cómputo, ya que el embebido en cuestión fue un sistema Raspberry Pi modelo B, lo que no impidió la ejecución del algoritmo aunque tardara tiempo considerable. Dicho tiempo de respuesta, mejoró con el uso de un sistema embebido con un poco más de poder de cómputo, pero de la misma familia. El embebido escogido posteriormente fue un Raspberry Pi 3 con un chipset Broadcom BCM2837, procesador ARMv8 de cuatro núcleos a 1.2GHz y 1GB de memoria RAM. Con estas nuevas características en el sistema embebido, se pudo ejecutar igual de rápido que en una computadora personal.

Es decir, el algoritmo post-cuántico de la familia SHA-3 se pudo ejecutar en dispositivos de recurso limitado con una velocidad de respuesta lenta, lo cual mejoró con el aumento en la capacidad del cómputo.

Resultados

Los resultados de la primera prueba se observan en la Tabla 1, en donde la entrada a la función SHA-3 es un archivo que contiene un millón de veces el mismo carácter, y dejan observar los tiempos de ejecución en milisegundos para el procesamiento de las funciones SHA-3 con salidas de longitud 224, 256, 384 y 512, lo cual se muestra en la Tabla 1. También, la Tabla 2 muestra los valores resultantes para las funciones de salida SHAKE. De igual forma el valor de entrada de la función es un archivo que contiene un millón de caracteres.

Tabla 1. Resultados con SHA-3

Tabla 2. Resultados con SHAKE

Para ambas Tablas la primera columna muestra las diferentes longitudes de salida del algoritmo de SHA-3 y SHAKE, respectivamente. La segunda columna expone los tiempos de ejecución, dentro de una PC, de cada una de las opciones de longitud de SHA-3. La tercera columna presenta los tiempos de ejecución, dentro del embebido Raspberry Pi de primera generación. Por último, la cuarta columna expone la relación que define cuántas veces es más lento el sistema embebido en comparación con un ordenador personal.

La Tabla 3 muestra la comparación, en tiempos de ejecución, entre las tres diferentes familias del algoritmo SHA dentro del embebido Raspberry Pi de primera generación. La primera columna muestra las diferentes longitudes de salida para las funciones SHA. La segunda columna muestra los resultados obtenidos de las familias SHA-1 y SHA-2 con cada una de las longitudes de salida. La tercera columna expone los tiempos de ejecución obtenidos de la familia de SHA-3 con las mismas longitudes de salida utilizadas para SHA-1 y SHA-2. Por último, la cuarta columna muestra la relación existente entre los tiempos de ejecución de SHA-1 y SHA-2 contra SHA-3, exponiendo el tiempo que tarda más la ejecución de la familia SHA-3 comparada con sus antecesores.

Tabla 3. Resultados de comparación.

De ahí, que los parámetros de salida de estas pruebas, permitieron determinar, por medio de un promedio de tiempos, qué tan posible o no es la ejecución de la familia de funciones SHA-3 dentro de sistemas embebidos con recursos limitados.

Conclusión

Los resultados obtenidos al ejecutar las funciones SHA-3 con salidas 224, 256, 384 y 512, dejan ver que el tiempo utilizado para ejecutar el proceso promedia entre uno y tres segundos, por lo que, a nivel computacional, es posible ejecutar una función hash post-cuántica dentro de un embebido de recursos limitados.

Los valores promedio obtenidos con los resultados dejan ver que sin importar la longitud de la salida obtenida, el dispositivo podrá tener en promedio, el mismo resultado.

Los valores obtenidos en la prueba tres, dejaron ver que una función post-cuántica puede ser ejecutada de manera exitosa dentro de los embebidos de bajos recursos computacionales, dado que al hacer la comparación con las familias previas SHA-1 y SHA-2, se puede observar que los tiempos de ejecución de la función SHA-3 no poseen un comportamiento tan distante de sus antecesoras, por lo que es posible utilizar e implementar aplicaciones que utilicen algoritmos post-cuánticos en vez de sus antecesoras.

Agradecimientos

Los autores agradecen al Instituto Politécnico Nacional dado que este trabajo fue financiado a través del proyecto SIP 20180505 y SIP 1917.

Referencias

[1] Mahmoud, Moustafa, et.al. (2017). A power resistant FPGA implementation of NTRUEncrypt.USA:IEEE.

[2] Basu Roy, Debapriya, et.al. (2018). Minimalistic perspective to public key implementations on FPGA. USA:IEEE.

[3] Dai, Wei, et.al. (2016). NTRU modular lattice signature scheme on Cuda CPUs. USA:IEEE.

[4] Chang, Yun-An, et.al. (2014). Post-Quantum SSL/TLS for emdedded systems. USA:IEEE.

[5] Jalali, Amir, et.al. (2017). Supersingular isogeny Diffie-Hellman key exchange on 64-bit ARM. USA:IEEE.

[6] Streit, Silvan, et.al. (2017). Post-Quantum key exchange on ARMv8: A New Hope for NEON made simple. USA:IEEE.

[7] Ghani, Aziz, et.al. (2013). Hash MD5 Function Implementation at 8-bit Microcontroller. Indonesia:IEEE.

[8] Kahri, Fatma, et al. (2013). An FPGA implementation of the SHA-3: The BLAKE Hash Function. Túnez:IEEE.

[9] Kahri, Fatma, et al. (2015). Efficient FPGA Hardware Implementation of Secure Hash Function SHA-256/Blake-256. Túnez:IEEE.

[10] F Dworkin, Morris J. "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions". Federal Inf. Process. Stds. (NIST

Bio

Alfonso de Abiega, Gina Gallegos-García y Kevin Delgado Vargas son profesores investigadores en la Escuela Superior de Ingeniería Mecánica y Eléctrica del lnstituto Politécnico Nacional, Unidad Culhuacán

Comentarios

I am very enjoyed for this blog

I am very enjoyed for this blog. Its an informative topic. It help me very much to solve some problems. Its opportunity are so fantastic and working style so speedy FOR MORE DETAILS.

50 Años de la Ingeniería de Software Problemas, Logros, Tendencias y Retos

Ivett Sanchez — Tue, 15 Jan 2019 19:15:39 +0000

50 Años de la Ingeniería de Software Problemas, Logros, Tendencias y Retos

Ivett Sanchez Tue, 01/15/2019 - 13:15

Publicado en

SG #58

Tejiendo nuestra red

Autor

Hanna Oktaba

Nota: Esta columna está basada en el contenido de la conferencia que ofrecí en CONISOFT’18, 24-26 de octubre de 2018, en San Luis Potosí.

Dediqué mi columna anterior a los 60 años de la computación en México, iniciados por la llegada de la primera computadora a la UNAM. Sin embargo, este no es el único aniversario redondo que nuestra comunidad debe festejar. Este año también se cumplen los 50 años del nacimiento de la Ingeniería de Software como disciplina.

Se reconoce a Margaret Hamilton, quien dirigió el desarrollo del sistema de navegación de la nave espacial Apolo por haber acuñado en 1965 el término “ingeniería de software”. Posteriormente el término también fue utilizado por personas como Anthony Oettinger (presidente de la ACM) en 1966, y Friedrich Ludwic Bauer (Comité de Ciencias de la OTAN) en 1967. Sin embargo, el nacimiento formal de esta disciplina se ubica en octubre de 1968, cuando el Comité de Ciencia de la OTAN, preocupado por lo que nombró como la Crisis de Software, convocó a los mejores científicos computacionales del momento a una reunión en Alemania.

A continuación les presento un breve resumen de los principales problemas que identificaron los asistentes, con citas del reporte de la reunión [1] en cursiva, a las cuales agrego mi visión personal de los mayores logros alcanzados durante estos 50 años.

Problemas y Logros

Proceso de desarrollo de software

Problemas en 1968

Falta una comprensión más completa del proceso de diseño del programa.
Construimos sistemas como los hermanos Wright construyeron aviones: “construye todo, empújalo por el precipicio, déjalo caer y vuelve a empezar.”

Logros hasta 2018

Durante los últimos 50 años hemos transitado por diferentes modelos: cascada, espiral, iterativo-incremental o ágil tipo Scrum. Hemos generado múltiples estándares para apoyar el desarrollo de software: CMM/CMMI, TSP/PSP, ISO/IEC 12207, 29110, 15504, MoProSoft, mps.Br o ESSENCE. Hemos integrado el cuerpo de conocimiento de la Ingeniería de Software (SWEBOK) y hemos generado el Manifiesto por el Desarrollo Ágil de Software, que está cambiando la forma de trabajar y las relaciones humanas.

A pesar de todos estos avances, tengo la sensación de que, en muchas ocasiones, seguimos imitando a los hermanos Wright. ¿Ustedes qué opinan?

Calidad de software

Problemas en 1968

Dificultades para lograr una fiabilidad suficiente en los sistemas, que cada vez son más integrados en las actividades centrales de la sociedad.
Particularmente alarmante son las fallas, aparentemente inevitables de un software, que pueden impactar una cuestión de vida o muerte.

Logros hasta 2018

La calidad de software tiene dos vertientes: del proceso y del producto. En la primera hemos avanzado introduciendo conceptos y técnicas de verificación y validación. El aseguramiento de calidad y la mejora de procesos también son un avance.

Con respecto a la calidad del producto tenemos un primer gran acuerdo en forma en el estándar ISO/IEC 25000 para identificar las características de calidad de software y su posible medición. Sin embargo, mi impresión es que para lograr la calidad nos enfocamos más en los ciclos de pruebas (testing) y sus respectivas correcciones, que en la prevención de defectos. ¿Ustedes qué opinan?

Costos

Problemas en 1968

T.J. Watson dijo que OS / 360 le costó a IBM más de 50 millones de dólares al año durante su preparación, y una inversión de al menos 5,000 años-hombre.
Los costos de desarrollo del software estaban integrados con los costos de desarrollo del hardware. No se cuantificaba el valor y costo del software como tal.

Logros hasta 2018

Para justificar el costo del software tuvimos que empezar a medir el tamaño del software. El primer intento fue usar el número de líneas de código (LOCs), pero fue criticado porque software con la misma funcionalidad puede tener diferentes tamaños LOCs dependiendo del lenguaje e incluso estilo de programación. Luego tuvimos una propuesta más sensata con los Puntos de Función ajustados a ciertos parámetros de complejidad, que eventualmente se convirtieron en el estándar ISO/IEC 14143, llamado de forma estelar “Puntos Funcionales Cosmic” :)

El problema de intangibilidad de software sigue causando estragos en la estimación de costos. La forma más popular es definir el precio en términos del costo por hora/hombre, pero hay gran discrepancia sobre cuál es la tarifa justa. Todavía es común encontrarse con quienes cuestionan por qué cuesta tanto el tiempo de las personas que desarrollan software, “si solo usan su cabeza y una computadora”. ¿Ustedes qué opinan?

Gestión

Problemas en 1968

Dificultades de cumplir fechas y especificaciones.
Dificultad para evaluar el avance real de un proyecto.
La gerencia de programación continuará mereciendo su mala reputación por la falta de efectividad en cuanto a costos y cronogramas.

Logros hasta 2018

Nos hemos apoyado en otras disciplinas. Por ejemplo, aprovechamos el cuerpo de conocimiento de la administración de proyectos PMBoK generado por el PMI. Su última publicación, el Agile Practice Guide, muestra su esfuerzo de estar al tanto de las tendencias. A pesar de estos avances, me temo que “la gerencia de programación continuará mereciendo su mala reputación” ¿Ustedes qué opinan?.

Profesión

Problemas en 1968

La ingeniería de software se encuentra en una etapa muy rudimentaria en comparación de otras ramas establecidas de la ingeniería.
Confrontaciones con ingenieros de hardware porque ellos son industriales y nosotros somos artesanos.

Logros hasta 2018

Para mejorar la profesionalización se han creado las carreras de ingeniería de software. La primera en el mundo fue fundada en 1996 en Rochester Institute of Technology por un profesor mexicano, el Dr. Fernando Náveda. La primera en México es la de la Universidad Autónoma de Yucatán en 2004.

También se han propuesto varios esquemas de certificación profesional como el Certified Software Development Professional (CSDP) de IEEE o el mexicano Estándar Técnico de Competencias para el Desarrollo de Software: Ingeniero de Software del NYCE (2014). Que yo sepa, ninguno ha tenido gran demanda. En mi opinión es porque el mercado laboral es relativamente inmaduro y prefiere las certificaciones de alguna habilidad técnica que profesional.

Los códigos de ética profesional de los desarrolladores de software tampoco han tenido gran difusión. A finales de los 1990s se creó el Código de Ética y Práctica Profesional de Ingeniería de Software de IEEE/ACM y recientemente (2018) se publicó el ACM Code of Ethics and Professional Conduct. Ambos merecen ser revisados y discutidos. Si se tomaran en cuenta nos beneficiaremos todos, pero si NO…nos amolaremos, también todos.

La profesionalización de los Ingenieros de Software ha tenido un avance significativo, pero creo que todavía nos falta elevar la conciencia del impacto que la calidad de nuestro trabajo tiene en la sociedad. ¿Ustedes qué opinan?.

Regresando a la preocupación general por la Crisis de Software del año 1968, a pesar de todos los avances y logros mencionados la situación no ha cambiado mucho. Según los reportes de Standish Chaos Group, el porcentaje de proyectos exitosos se mantiene de manera constante en aproximadamente 30%. Esto es buena noticia para ustedes, tienen mucho que innovar :).

El Futuro

El futuro de la ingeniería de software es muy desafiante. Para fundamentarlo, presento un muy breve resumen de algunas tendencias y retos abordados en la conferencia “The Future of Software Engineering” [2].

Tendencias

La computación en la nube reduce costos de arranque, y los ambientes de desarrollo en la nube facilitan el desarrollo de software remoto.

Se reduce el uso de computadoras personales a favor de los dispositivos móviles, pero su variedad es abrumadora.

Los usuarios son móviles, nómadas y "siempre conectados”.

Han surgido nuevos tipos de aplicaciones: Smart City, Internet de las Cosas (IoT), Realidad aumentada/virtual.

Inteligencia Artificial: robótica, machine learning, procesamiento de lenguaje, reconocimiento de imágenes …ya no es ciencia ficción.

Los sistemas ya casi no se hacen desde cero, evolucionan a sistemas complejos.

Retos

Estas tendencias tendrán que modificar la forma de abordar problemas y dar soluciones en la Ingeniería de Software. Sus próximos retos son los siguientes:

Se requiere el cambio profundo y radical en los métodos y técnicas utilizados para concebir, diseñar, desarrollar, probar y desplegar software.

Escalabilidad de procesos de software necesaria por la complejidad de productos y exigencia de “time to market”.

La calidad y, sobre todo, la seguridad del software se están volviendo aún más críticas.

El número de ambientes/plataformas objetivo que un desarrollador debe considerar para desarrollo de software está aumentando significativamente.

El software debe diseñarse para minimizar el uso de los recursos de hardware y de comunicación y, en consecuencia, reducir el consumo de energía (Green IT).

Conclusión

Para concluir esta columna les quiero recordar mi lema:

“La calidad de nuestras vidas depende de la calidad del software, y la calidad del software depende de la calidad de sus creadores y de las organizaciones que los respaldan.”

Referencias

P. Naur, B. Randell. Software Engineering: Report of a conference sponsored by the NATO Science Committee. Garmisch, Germany, 1968. https://sg1.run/xq
A.Fugetta y E. Di Nitto, Proceedings on the Future of Software Engineering (FOSE). Hyderabad, India, 2014. https://sg1.run/xr

Bio

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares.

SG #58

Estudio de Salarios SG 2019

Publicado en

Autor

Agradecimientos

Fuente de los datos y contexto

Salario medio

Actividades y roles

Experiencia

Ubicación geográfica

Estudios

Tipo de empresa y esquema

Género

Conocimientos

Comentarios

Las Mejores Empresas para Trabajar en Software 2018-2019

Publicado en

Proceso de evaluación

El top 20

OpenMarket Considera su Presencia en Guadalajara como Clave de su Éxito

Publicado en

El impacto de los lenguajes propietarios de propósito particular: Una visión panorámica

Publicado en

Autor

1. Lenguajes - Patrones

2. Lenguajes formales

3. Gramáticas

4. Jerarquías de Lenguajes

5. Semántica formal

6. Máquinas Abstractas y Lenguajes

7. Lenguajes y Compiladores

Lenguajes de Computación (LCs) y Lenguajes de Programación (LPs)

Ejemplo Integrador

Cómputo Cuántico

Publicado en

Autor

Cuando el Futuro nos Alcance: ¿En qué podemos utilizar computadoras cuánticas?

Publicado en

Autor

Solución de problemas de optimización

Internet cuántico

Desarrollo y Simulación de Algoritmos Basados en Temple Cuántico

Publicado en

Autor

Procesamiento Cuántico para Redes de Sensores

Publicado en

Autor

Criptografía Post-cuántica en Sistemas con Recursos Limitados

Publicado en

Autor

Un poco de historia

Desempeño de un algoritmo post-cuántico para el servicio de integridad

Ejecución en sistemas con recursos limitados

Resultados

Conclusión

Agradecimientos

Comentarios

50 Años de la Ingeniería de Software Problemas, Logros, Tendencias y Retos

Publicado en

Autor

Problemas y Logros

Proceso de desarrollo de software

Calidad de software

Costos

Gestión

Profesión

El Futuro

Tendencias

Retos

Conclusión

Tags