Al día de hoy como hace unos años, sigue siendo complicado entender la realidad de la industria del software y la ingeniería que existe detrás de ella. ¿Por qué es tan complicado crear y estabilizar una empresa en nuestra industria? (dedicada a la fabricación de software), ¿Por qué se hace complicado mantener el flujo de caja en este tipo de compañías?, ¿Por qué cada día más y más empresas de software toman otras alternativas como el Outstaffing (que es sencillamente alquilar el talento humano que tanto ha costado conseguir) para dar sustento financiero a la compañía? Me hago estas preguntas a menudo cuando voy a trabajar, y es fácil perderlas de vista en mi rutina como analista, pero son la realidad de todos los que han asumido el reto de edificar una empresa, en una industria que apenas tiene alrededor de 70 años de historia.
Aunque las preguntas de la industria se pierden entre mis tareas, como un ingeniero de software común y corriente, no estoy exento de preguntarme por otros interrogantes, ¿Por qué recuerdo tan poco del fundamento teórico de mi profesión? ¿Por qué estudié 4 semestres de física y 5 semestres de cálculo teórico en mi carrera universitaria?, ¿Por qué mi carrera realmente empezaba a volverse edificante cuando la practica era incluida?, ¿Por qué cuando ingresé a mi primer trabajo, podía rescatar mucho de lo practico que había aprendido en mi carrera y tan poco de la teoría?, todos estos interrogantes evidencian la realidad de la ingeniería de software, que a veces se puede pensar que al parecer tratamos de formarnos como ingenieros tomando como guía el camino de aprendizaje de otras ingenierías, haciendo que aprendamos de todo un poco, pero perdiendo de vista una línea subyacente común (una identidad), que hasta el día de hoy no hemos definido como industria. Sin embargo, no debemos ser tan duros con nuestra disciplina o con nosotros mismos como practicantes, como lo dije inicialmente, esta disciplina apenas tiene alrededor de 70 años de historia (si tenemos en cuenta como surgimiento real de la misma la época de la segunda guerra mundial), y aun así ha llevado a la humanidad a una nueva era.
Como ingeniería deberíamos contar con prácticas rigurosas, disciplinadas y profesionales para el desarrollo de software (como las que observamos en la ingeniería civil), pero lo que realmente hemos adoptado como Ingeniería de Software es un conjunto de prácticas tomadas de disciplinas externas, como administración de proyectos, diseño y control de calidad, teniendo en cuenta que la idea inicial era tratar al software como un producto manufacturado, es decir, construido sobre una línea de producción, en la cual se aplica ingeniería en las fases que todos los practicantes del software conocemos: recolección de requerimientos, análisis, diseño, construcción y pruebas. Como tal esta perspectiva de manufactura tiene sentido en otras disciplinas, en las cuales las fases iniciales del trabajo tienen fuertes fundamentos teóricos y prácticos, por lo cual el esfuerzo inicial del proceso es redituable, lo que generalmente en la industria del software poco lo es, lo anterior ha llevado a la industria a devaluar el trabajo de los desarrolladores, que son realmente quienes hacen que el software trabaje, independientemente de lo que los planos iniciales o diseños afirmen. Teniendo en cuenta lo anterior, hoy en día se debate si lo que hacemos en ingeniería de software, se debería tratar como un arte, y aunque para muchos lo anterior debería tomarse como algo de lo cual deberíamos sentirnos triunfalistas, lo que realmente se está afirmando, es que la ingeniería de software aún es un proceso artesanal, y eso nos lleva a preguntarnos si somos ingenieros o artesanos. El desarrollo de software como tal es una disciplina artesanal, la cual es construida sobre la experiencia de los maestros del software, la cual guía a la comunidad a construir mejores soluciones y con mayor calidad. Además, las prácticas agiles para el desarrollo de software, han hecho posible que soluciones de gran tamaño no pierdan calidad en este proceso artesanal.
Pero como tal este proceso artesanal no puede llevarnos tan lejos, para explicarlo, hagamos un paralelo con la ingeniería de la construcción.
La Sagrada Familia, Barcelona, España. Créditos foto: de Manuel Torres Garcia
Conocemos muchas maravillas en el mundo que fueron construidas por grandes artesanos, tales como castillos de la edad media, hermosas catedrales o estatuas de gran tamaño, desafortunadamente estas grandes obras fueron increíblemente costosas y tomaron muchísimo tiempo en finalizarse (algunas no se han terminado después de más de un siglo, como la Catedral de la Sagrada Familia en Barcelona), inclusive algunas de estas obras terminaron en grandes desastres después de algunos años. Ahora bien, las construcciones modernas como los rascacielos, toman muchísimo menos tiempo en construirse y la posibilidad de que terminen en desastre es mínima, todo esto gracias al desarrollo a través de los años de un verdadero enfoque de ingeniería. Todas las construcciones modernas, desde la casa más pequeña hasta el edificio más grande, tienen sólidos fundamentos en ciencia de materiales y teoría de estructuras, y los profesionales del área utilizan estos fundamentos teóricos como una base principal para el diseño disciplinado y cuidadoso de las estructuras que desean construir, y aunque a veces pueden fallar, esta misma teoría guía al profesional (ingenieros civiles o arquitectos) a encontrar la causa del error y la solución para el mismo. La ingeniería de construcción además de ser un excelente paralelo para nuestra disciplina, es un ejemplo perfecto de como una ingeniería combina un proceso artesanal con una base teórica sólida, haciendo posible educar de manera efectiva a nuevos profesionales en la creación de nuevas estructuras y en la solución de problemas de las mismas. Lo anterior nos da una perspectiva de la realidad de la ingeniería de software, y como tal desde este punto de vista, no es realmente una disciplina de la ingeniería. Ahora bien, ¿cómo deberíamos proceder?, talvez deberíamos saltarnos la parte en la que pensamos en reclamar nuestro dinero de vuelta a nuestras respectivas universidades, y centrarnos en el reto que tenemos por delante, refundar la ingeniería de software.
Hace unos pocos años algunas organizaciones de la industria del software asumieron este reto, a través de la creación de la comunidad SEMAT (Software Engineering Method and Theory), la cual tiene la misión de refundar la ingeniería de software basada en una teoría sólida, principios probados y mejores prácticas. Algunos de sus miembros son ABB, Ericsson, Fujitsu UK, Huawei y TCS, junto a universidades como la Carnegie Mellon, y con el respaldo del Object Management Group (OMG), y personajes como Ivar Jacobson, Bertrand Meyer y Richard Mark Soley. SEMAT tiene el objetivo de soportar la creación de un terreno común, un núcleo o un pilar base para la ingeniería de software. Actualmente SEMAT tiene siete capítulos que se trabajan alrededor del mundo, con el fin de establecer entre las diferentes comunidades de software de nuestro medio el núcleo de la ingeniería de software, los principios probados a través de los años y las mejores prácticas de las fábricas de software de hoy en día. Para este fin SEMAT ha creado Essence, que se define como una primera aproximación a la estandarización de la ingeniería de software, es decir el terreno común, el núcleo que por mucho tiempo no habíamos definido. Este estándar permite a los equipos entender y visualizar el progreso y el estado del trabajo realizado en ingeniería de software independientemente del método o prácticas utilizadas. Además, les permite a dichos equipos la creación de métodos de trabajo a partir de sus mejores prácticas, y de esta manera contribuir a la refundación de la ingeniería de software. Essence consiste básicamente en la definición de tres elementos:
- Un medio para medir el progreso y la salud de un esfuerzo.
- Una categorización de las actividades necesarias para hacer progresar un esfuerzo.
- Un conjunto de competencias necesarias para llevar a cabo dichas actividades.
Teniendo en cuenta estos elementos, él núcleo se enfoca en la importancia de entender como un esfuerzo está progresando, y para ello Essence define siete dimensiones o alfas para medir dicho progreso: Oportunidad, StakeHolders, Requerimientos, Sistema de Software, Trabajo, Equipo y la Manera de trabajar (métodos).
Cada alfa tiene un conjunto de estados que establecen puntos a lo largo de las dimensiones de todo el progreso del esfuerzo. Cada estado cuenta con una lista de chequeo con sub estados, la cual ayuda a establecer la ubicación actual de un esfuerzo en el contexto de un determinado alfa, además permite establecer los sub estados necesarios para avanzar al siguiente estado. Un ejemplo más tangible de lo anterior es un conjunto de cartas, que puede ser fácilmente administrado por un practicante de ingeniería de software, y de esta manera mantener actualizado el estado de un esfuerzo.
Este es un breve acercamiento a los resultados del trabajo realizado por SEMAT con el objetivo de refundar la ingeniería de software. Toda esta información puede ser ampliada a través de la documentación de Essense que es de acceso gratuito en el sitio web de la comunidad www.semat.org. Como podemos observar la comunidad de ingeniería de software en el mundo ha entendido el problema que inicialmente planteamos en este artículo, y se están realizando esfuerzos con el fin de establecer las bases de nuestro trabajo como ingenieros. Pero cabe resaltar que el trabajo de SEMAT aún está en progreso, Essence es apenas un primer acercamiento a la refundación de la ingeniería de software, y podrían existir paradigmas que, al parecer de cualquiera de nosotros no han sido incluidos dentro de este terreno común, y por lo tanto podríamos contribuir con esta iniciativa. Además, debemos recordar que SEMAT trabaja en tres elementos principales para esta refundación: una teoría sólida o un terreno común, principios probados y mejores prácticas, estos dos últimos aún están siendo estudiados por los investigadores de esta comunidad, y como tal las prácticas y métodos nacen todos los días con nuestro trabajo, por lo cual una manera de contribuir con esta iniciativa podría ser cultivar estas prácticas y métodos en el terreno común de Essence, y compartir nuestros frutos con la comunidad del software. Y como un profesional que no está dedicado a la investigación, lo único que tengo por ahora son agradecimientos a la comunidad SEMAT por esta iniciativa, una comunidad de profesionales del software que están contribuyendo ahora mismo con su trabajo y experiencia a la refundación de la ingeniería de software, o como lo afirmó Ivar Jacobson, “… O, talvez, fundándola por primera vez”.
BIBLIOGRAFÍA
- Dr. Ivar Jacobson, Dr Pan-Wei Ng, Paul McMahon, Ian Spence, Svante Lidman, P. 2012. The Essence of Software Engineering: The SEMAT Kernel; http://queue.acm.org/detail.cfm?id=2389616. Dr. Ivar Jacobson, Dr Pan-Wei Ng, Paul McMahon, Ian Spence, P. 2014. Major-league SEMAT—Why Should an Executive Care; http://queue.acm.org/detail.cfm?id=2590809.
