Como llegué a competir con Ivar Jacobson

Al principio de los 80´s cumplí 30 años, estuve por terminar el doctorado en la Universidad de Varsovia, Polonia. El tema de mi tesis fue la formalización lógica del concepto de apuntador (referencia) en los lenguajes de programación de entonces: Simula-67 y C. Por cierto, para la información de las nuevas generaciones, Simula-67 fue el primer lenguaje que introdujo el concepto de clase, objeto, herencia, métodos virtuales y co-rutinas (concurrencia); definido por tres noruegos en 1967 – Dahl, Nygaard y Myrhaug. Como ven los lenguajes orientados a objetos ya están por cumplir 45 años.

En 1983 llegué a México y me dediqué a enseñar en la maestría en Ciencias de la Computación del IIMAS los conceptos de los lenguajes orientados a objetos, empezando por Simula 67 y luego C++. Las especificaciones algebraicas de  los tipos de datos, como colas, pilas, árboles y los conceptos de concurrencia, paralelismo y distribución fueron también de mis temas favoritos. Al cumplir los 40 años, en la década de los 90´s, viví el auge de los lenguajes orientados a objetos. En la revista “Soluciones Avanzadas”, precursora del Software Gurú, editada por Carlos Vizcaíno, estuvimos difundiendo el conocimiento sobre este tipo de lenguajes comparándolos con los lenguajes funcionales (como LISP) y basados en la lógica (como Prolog). Sin embargo, para mí lo más importante de la década de los 90’s fue la publicación de los diferentes libros sobre los métodos de análisis y diseño de los sistemas implementados con los lenguajes orientados a objetos (OO).

En este entonces me percaté de que los lenguajes OO no son el todo del conocimiento que necesita un desarrollador de sistemas de software para hacer buen trabajo. Faltaba algo más, las fases conceptuales del análisis (entendimiento de lo  que se requiere) y del diseño (propuesta abstracta de la solución computacional) eran las que hacían falta. En esta época, Grady Booch [1], James Rumbaugh [2] e Ivar Jacobson[3] habían publicado libros importantes sobre estas fases. Los libros ofrecían las primeras prácticas basadas en la experiencia. Gracias a sus libros estos tres señores se vuelven mis ídolos.

Cuando Booch logra juntar a Jacobson y a Rumbaugh en la empresa Rational y juntos en 1995 proponen ante el Object Management Group (OMG) a UML (Unified Modeling Language) como el estándar del lenguaje de modelado OO, la aceptación y el éxito fueron inmediatos. Posteriormente, juntos escriben tres libros [4,5,6] que marcaron la historia de los procesos de desarrollo de software basados en OO (Proceso Unificado) y el modelado de las vistas abstractas de los sistemas OO (UML).

A partir de este momento, los contenidos de los cursos de la Ingeniería de Software en la UNAM, que ofrecemos con Lupita Ibargüengoitia, obligan a nuestros alumnos de la licenciatura y de la maestría a aprender y usar en los proyectos a UML y los elementos del Proceso Unificado. Llega el milenio nuevo, y al cumplir los 50 años me atrevo a desafiar, sin proponérmelo conscientemente, a Software Engineering Institute (SEI). Su modelo de SW-CMM y posteriormente CMMI fueron los referentes obligados para la industria de software. Pero yo me atrevo a pensar que los consejos que ofrece CMMI se pueden expresar de manera más sencilla.

En 2002 comienza la iniciativa de PROSOFT para fortalecer a la industria mexicana de software. Como presidenta de la AMCIS (extinta Asociación Mexicana para la Calidad en Ingeniería de Software) propongo a la Secretaría de Economía desarrollar un modelo mexicano de procesos (basado en las versiones de los modelos y estándares existentes en ese entonces: CMMI, ISO/IEC 12207 e ISO 9000). El argumento fue el siguiente: estos modelos y estándares son muy buenos, pero… nuestra industria de software está conformada en 90% (¿o más?) por las MIPYMES. Primero hay que apoyarlas para que crezcan y se consoliden y luego que busquen a los modelos para más maduros, como es CMMI. Esta fue la idea principal que llevó a la creación de MoProSoft y su conversión en el estándar nacional.

El esfuerzo posterior de probar MoProSoft en Iberoamérica, a través del proyecto COMPETISOFT (2006-2008), y su aceptación inesperada como base para el estándar ISO/IEC JTC1 SC7 Software and System Engineering (2006-2011), que culminó en la publicación del ISO/IEC Basic Profile en 2011 [7], ya es otro cuento. En México, creo que hasta la fecha pocos han entendido el valor de MoProSoft y, sobre todo, el significado para el país de elevarlo a nivel del estándar internacional. Mientras que en México se dispute si apoyar o no con financiamiento este proyecto, Brasil ya convirtió a ISO/IEC 29110 Perfil Básico en el estándar nacional y seguro lo va aprovechar pronto.

Pero no me quejo, cumplí 60 años en 2011 y el destino me abrió nuevos horizontes. Primero, mi ídolo Ivar Jacobson convocó en 2010 a la comunidad de la Ingeniería de Software a refundar esta disciplina bajo la iniciativa de SEMAT (Software Engineering Method and Theory). En su momento les hice el reporte de esta rebeldía en mi columna de SG no. 32. El año pasado participé en la fundación del SEMAT Latino América, de lo que también les conté en el no. 34 de SG.

En este mismo año 2011 la iniciativa del SEMAT se convirtió en una convocatoria del ObjectManagement Group para recibir propuestas de “A Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM)”.

Justamente cuando salió la convocatoria de OMG, estuve reflexionando sobre el enfoque tradicional sobre los procesos. Los modelos existentes recogen muchas buenas prácticas, sea CMMI, MoProSoft, ISO/IEC 12207, ISO/IEC 29110. Entonces ¿por qué a las empresas les cuesta tanto trabajo de adoptarlos? Por otro lado, aparecieron métodos ágiles, que prometen “el mar y las estrellas con 13 meses sin intereses”, que son una tentación muy fuerte pero incierta. Algo no está funcionando. Empecé a vislumbrar otro enfoque. En vez de “vender” a las empresas los modelos que tienen que ponerse “a chaleco”, que tal si les damos las herramientas sencillas de documentar sus prácticas diarias y que ellos mismos las modifiquen en función de lo que vayan aprendiendo de la experiencia o del conocimiento traído del exterior.

Así que decidí lanzarme a la aventura de participar en la convocatoria de OMG. Aproveché que ya tengo dos manos de obra “barata”, que son mis alumnos de doctorado: Miguel Ehécatl Morales Trujillo y Magdalena Dávila Muñoz. Mi ingenuidad, consecuencia de trabajar tantos años en la academia, no me avisó que para participar en la OMG necesito dinero. Para ser miembro de la OMG con derecho de proponer nuevos estándares y votar, hay que pagar $5,500 USD anualmente. Por eso en su momento hice un llamado de apoyo económico a este proyecto de investigación a través del infalible Software Gurú, y lo volveré a repetir en esta columna.

En el noviembre del año pasado enviamos a OMG la carta de intención de participar en la convocatoria de FACESEM. El 22 de febrero 2012 mandamos la propuesta bajo el nombre de KUALI-BEH Software Project Common Concepts. KUALI en náhuatl significa “bueno” y BEH en maya significa “camino”. Estamos proponiendo un “buen camino“ para definir las prácticas y métodos para el desarrollo de software, que las propias organizaciones capturen, adapten y mejoren en función de su experiencia y maduración. Al día siguiente nos enteramos de que somos competidores de, ni más ni menos, Ivar Jacobson.

El marzo 21, en Reston cerca de Washington, nos tocó presentar KUALI-BEH ante la comunidad de OMG. Un día antes Jacobson intentó convencernos para que nos uniéramos a su propuesta llamada ESSENCE. Le dijimos que necesitamos tiempo para pensarlo, por lo tanto el 21 de marzo nos presentamos como propuestas competidoras. La nuestra recibió buenos comentarios, que nos alentaron mucho. El día siguiente Jacobson nos pidió que le hiciéramos la propuesta de unir ambos enfoques, la cual se la enviamos a finales de marzo. Ahora la pelota está de su lado (más bien de su grupo: Fujitsu, IBM, Model Driven Solutions y otros) En agosto hay que enviar a OMG una propuesta mejorada (o fusionada con la de Jacobson) y defenderla en la reunión de septiembre en Jacksonville. Mientras tanto estamos probando KUALI-BEH con la comunidad mexicana de desarrollo de software a través de un Taller Colaborativo en Métodos de Ingeniería de Software, que se realiza en modalidad virtual y presencial.

Para continuar necesitamos recursos. Les reitero la invitación para apoyar este proyecto de investigación aplicada. Las aportaciones pueden ser en efectivo (con recibo de la UNAM deduciblede impuestos) o en especie (inscripciones, boletos de avión, hoteles, libros, equipo de cómputo). Los interesados favor de comunicarse directamente conmigo hanna.oktaba@ciencias.unam.mx. Por lo pronto quiero agradecer públicamente a los primeros patrocinadores (empresas y personas físicas): Magnabyte, Software Guru, Ultrasist, JPEConsultores, Innevo, Hugo Rojas Martínez y Evaristo Fernández Perea. A los que piensan que al cumplir 30 años se les acaba la vida les puedo asegurar que “Más sabe el diablo por viejo…”. No se pierdan el siguiente capítulo.

Referencias

[1] G. Booch, “Object Oriented Design with Applications”, The Benjamin/Cummings, 1991.

[2] J. Rumbaugh at al., “Object-Oriented Modeling and Design”, Prentice Hall, 1991.

[3] I. Jacobson at al., “Object-Oriented Software Engineering, A Use Case Driven Approach”, Addison-Wesley, 1992.

[4] G. Booch, J. Rumbaugh y I. Jacobson, “The Unified Modeling Language, User Guide”, Addison-Wesley, 1999.

[5] I. Jacobson, G. Booch y J. Rumbaugh, “The Unified Software Development Process”, Addison-Wesley, 1999.

[6], J. Rumbaugh, I. Jacobson y G. Booch, “The Unified Modeling Language, Reference Manual”, Addison-Wesley, 1999.

[7] (http://standards.iso.org/ittf/PubliclyAvailableStandards/c051153_ISO_IEC_29110-5-1-2_2011.zip )