Afinales de agosto de 2005 el International Process Research Consortium (IPRC) tuvo su cuarta reunión en Dublín, Irlanda. Fue mi primera visita a este país y me sirvió para cambiar algunos prejuicios que tenía. Por ejemplo, no me gustaba la cerveza Guinness y descubrí que me gusta mucho; las chuletas de borrego tenían un olor que me molestaba y me di cuenta que las chuletas irlandesas tienen un olor muy agradable. También, tenía la idea de que México es el único país donde cualquier persona, bajo una modesta dosis de tequila o cerveza, expresa sus enormes dotes para cantar, bailar y divertirse, pero descubrí que lo mismo les pasa a los irlandeses quienes sustituyen la dosis de tequila por la de whisky.
Regresando al tema de la reunión de IPRC, ya fue la cuarta de las seis previstas y ya nos tocaba definir el esquema general del documento final sobre el mapa de líneas de investigación en procesos de software para los próximos diez años. Para que este mapa sea útil, se acordó describir “el punto de partida” y definir varios posibles destinos a alcanzar en el futuro. Los destinos se generarán a partir de diversos escenarios, que se han trabajado en la reunión anterior, y la descripción del estado actual sintetizará los elementos identificados en las primeras dos reuniones.
Para organizar el trabajo, que duró tres días, nos dividieron en dos grupos que llamaron Push y Pull. El objetivo del primer grupo es describir las fuerzas que empujan la investigación en procesos de software en ciertas direcciones. Mientras que el otro grupo identificará las fuerzas que “jalarán” la investigación a futuro, según el contexto de cada escenario destino.
El primer grupo, en el cual participé, tuvo como tarea revisar los documentos del trabajo previo y otros, que fueron proporcionados por los miembros del consorcio, para identificar tendencias y realidades en el desarrollo de sistemas. Llegamos a identificar 227 ideas que hay que clarificar, eliminar duplicidades y clasificar de tal manera que queden entendibles. Barry Boehm está coordinando los trabajos de este grupo y fue él quien nos propuso una primera aproximación de la estructura del contenido.
Uno de los momentos curiosos durante el encuentro fue la discusión sobre la definición del proceso de software. Desde las reuniones pasadas ya se había mencionado que no podemos proponernos definir las futuras líneas de investigación en procesos de software mientras no tengamos un acuerdo sobre este concepto. Para remediar el asunto, se delegó a dos de los miembros la labor de poner por escrito las posibles definiciones y su justificación. El documento que prepararon reveló que existen por lo menos dos versiones antagónicas de la interpretación de lo que es un proceso. La escuela que yo llamaría SEI, opta por preocuparse en “qué hacer durante la realización de un proceso con el fin de obtener resultados deseados”, mientras que la escuela ISO/IEC15504 prefiere especificar “qué es lo que se propone lograr a través de un proceso”. Ambos enfoques son justificables y de alguna manera complementarios. Sin embargo, debido a que entre los miembros del consorcio hay “fundamentalistas” de ambas escuelas, la discusión final sobre este tema nuevamente se pospuso hasta la siguiente reunión.
Otro tema polémico surgió durante el panel con los representantes de la industria participantes en el consorcio. Trataron de llamar la atención del grupo académico sobre el enfoque del documento resultante de nuestro trabajo. Dijeron que éste no puede reducirse simplemente a una lista de temas de investigación “chidos” o “cool”, sino que debe de incluir una clara relación de estos temas con las necesidades de la industria y de la sociedad en general. Todo esto con la finalidad de que los organismos que otorgarán el financiamiento para la investigación en procesos de software tengan disponible una justificación convincente de los beneficios esperados.
En esta ocasión tuvimos un día extra de trabajo dedicado a un taller conjunto de IPRC con Irish Software Engineering Research Consortium. Este último agrupa representantes de la academia e industria de software local. Al escuchar su presentación me dio envidia de la buena. Sus objetivos son hacer investigación “amigable” para la industria local e internacional, y construir equipos de investigación y desarrollo de alta calidad. Para armonizar la investigación con las necesidades de la industria decidieron enfocar su atención en resolver los problemas de tres dominios específicos: sistemas automotrices, aparatos médicos y sistemas financieros. Y, además, como su país tiene la política de apoyo a la industria de software porque entienden que el software “tiene la fuerza de cambiar al mundo”, obtuvieron los recursos para convertir el consorcio en un Centro.
Finalmente, un representante de Australia presentó los argumentos por los cuales 275 organizaciones dedicadas al desarrollo de software de su país expresaron su falta de interés por adoptar CMMI. El más importante de los argumentos es que la relación costo-beneficio no está muy clara. El costo es muy alto, el tiempo de adopción muy largo y los beneficios a corto plazo dudosos. Prometo corroborar estos datos personalmente porque en noviembre tenemos la quinta reunión en Australia.
Acerca del autor
La Dra. Hanna Oktaba es profesora en la Facultad de Ciencias de la UNAM. Es fundadora y vicepresidenta de la Asociación Mexicana para la Calidad en la Ingeniería de Software. Actualmente dirige el proyecto con el cual se creó la norma mexicana para la industria de software.
- Log in to post comments