Columna

Como llegué a competir con Ivar Jacobson

lasr21 — Mon, 09 Jul 2012 16:49:59 +0000

Como llegué a competir con Ivar Jacobson lasr21 Mon, 07/09/2012 - 11:49

Publicado en

SG #36

Columna

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 )

Bio

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

Trabajo Colaborativo

Anonymous — Thu, 01 Mar 2012 14:00:00 +0000

Trabajo Colaborativo Anonymous Thu, 03/01/2012 - 08:00

Publicado en

SG #35

Columna

Hoy, la tecnología nos permite y nos obliga a trabajar en forma colaborativa con perfiles de personas cada vez más diversos. Hace pocos años, un equipo de sistemas estaba compuesto por ingenieros que desarrollaban software manejando distintos lenguajes de programación. Con la llegada de las interfaces gráficas, tuvimos que reconocer una rama de la informática a la cual no dábamos mucho crédito: el diseño, y con ello tuvimos que comenzar a convivir con gente que vivía de la estética. Ya no hablábamos entonces de diferentes lenguajes de programación, sino de distintas formas de ver lo mismo. En una pantalla en la cual un ingeniero ve datos, un diseñador ve pixeles.

Así, por ejemplo, en un proyecto en el que trabajaba hace unos años, encontramos que unos datos estaban mal y quise validar el error con alguien del equipo de diseño. Pero cuando le dije : “Tadeo mira: esto está mal, ¿no?”, su respuesta fue: “¡Sí! ¡Está dos pixeles corrido a la derecha!”. En ese momento me di cuenta de que veiamos el mundo desde perspectivas totalmente diferentes. A la larga esto es bueno porque nos enriquece, pero al principio no es sencillo lograr esa colaboración. Si a ello le agregamos nuevas tecnologías y la consabida presión del cliente final, la ecuación se complica aún más, especialmente en grandes organizaciones.

¿Pero por qué resulta tan complejo el trabajo colaborativo? Al fin y al cabo, las organizaciones constan de estructuras, que son válidas y básicas para la operación de las mismas, y que simplemente hay que seguirlas para cumplir con los objetivos del negocio. Sin embargo, muchas veces estas estructuras no resultan tan funcionales a la hora de llevar a cabo los proyectos, generando problemas burocráticos. Esto quizás podría llevarnos a pensar que los proyectos deberían llevarse a cabo en forma totalmente anárquica, pero esta tampoco es la forma correcta.

Antes que nada, ante el planteamiento de un proyecto debemos tener claro cuál es el objetivo del mismo. Por lo general, el objetivo de cualquier proyecto informático es obtener en forma eficiente un producto de alta calidad, que cumpla con las expectativas del usuario final. Para cumplirlo, se necesita la mayor eficiencia en todo el ciclo de desarrollo, desde la recopilación de información hasta la puesta en producción del sistema. Es así que cada uno de los actores en las distintas fases tiene la misma importancia en la obtención del objetivo.

Uno de los factores de fracaso más comunes en los sistemas es que los usuarios finales tienen un bajo índice de adopción de los sistemas nuevos, no porque se nieguen a usarlos o por falta de voluntad, sino porque el sistema no está adecuado a sus necesidades. ¿Cómo puede suceder esto si se ha involucrado al responsable de área desde el principio?

Este es uno de los puntos donde hay que romper con estructuras jerárquicas tradicionales para obtener el mayor conocimiento. Es imprescindible ir a la fuente correcta para obtenerlo, y esta no es otra que el usuario final, el operativo. Por otra parte, cuando el usuario final colabora en el proyecto, podemos lograr que lo sienta como parte de sí y se comprometa con el mismo. Uno de los grandes beneficios de esta forma de trabajo es que se obtiene información de mayor calidad, ya que al ser el usuario parte activa del proyecto aporta valor, esas pequeñas cosas que suelen perderse en las entrevistas porque al parecerle obvias al entrevistado sin querer las omiten y como el entrevistador las desconoce, no pregunta por ellas.

Al trabajar en forma conjunta estos detalles, se puede lograr un gran avance en etapas muy tempranas del proyecto, y conseguir que al final del mismo el usuario ya conozca el sistema. Esto le dará seguridad y confianza para utilizarlo, y para darle apoyo a sus pares.

Trabajando de esta manera, si bien existen roles definidos, todos se sienten tanto parte del sistema como que aportan a la construcción del mismo, y no sienten que es una decisión de laboratorio que alguien definió un día y que ahora le imponen.

Por el lado de desarrollo, los roles son bastante clásicos: un gerente de proyecto cuyas tareas están relacionadas con la planificación, seguimiento y control del proyecto, y quien debe liderar y administrar los recursos, realizar las estrategias para llegar a los objetivos, cumplir cronogramas, administrar los cambios de requerimientos e interactuar con todos los otros miembros del proyecto. Luego tenemos al referente técnico, cargo cuyo perfil es de un desarrollador de muy alto nivel, que debe ser un referente para el equipo, capaz de marcar pautas sobre distintas tecnologías, y las pautas de desarrollo a utilizar, por lo cual debe ser alguien que está muy actualizado. Adicionalmente debe haber un responsable de desarrollo, que es quien liderea al equipo, se encarga de las estimaciones de tiempo de las funcionalidades a desarrollar, organiza el trabajo de los desarrolladores de cada módulo, le brinda apoyo funcional y técnico a los desarrolladores, le hace seguimiento al cronograma y realiza la validación de lo desarrollado. Y finalmente está el desarrollador, quien aplica las pautas de desarrollo en la implementación del sistema, identifica potencialmente nuevas pautas, realiza el testing unitario y el testing integrado, y colabora también con el seguimiento del cronograma. Con un equipo así, aplicando el trabajo colaborativo, se podrá obtener mejores resultados, ya que cada una de sus visiones enriquecerá el producto final.

Bio

Anibal Gonda es Director de Desarrollo de Negocios de GeneXus Internacional. anibal@genexus.com