19
Analysis to the Culture Shock in Scientific Software Development
Análisis al Choque de Culturas en el Desarrollo de Software Científico
Charles Boleros
Agencia Gubernamental de las Ciencias Computacionales. Boleros.Charles(AT)gacs.ca
INFORMACIÓN DEL ARTÍCULO
Tipo de artículo: Reflexión
Historia del artículo
Recibido: 17-03-2013 Correcciones: 10-06-2013 Aceptado: 12-06-2013
Categories and Subject Descriptors
K.3.2 [Computers and Education]: Computer and Information Science Education –Computer science education.
General Terms
Software Engineering, Requirements Engineering, Computational
Complexity, Algorithmic Analysis.
Keywords
Software development, Software Engineering, IT projects, scientific software.
Palabras clave
Desarrollo de software, Ingeniería de Software, proyectos informáticos, software científico.
ABSTRACT
In this paper are analyzed two cultures, the scientists who develop their own software and software engineers who develop scientific software, It describes some of the problems that arise when both cultures come together to develop scientific software, and discusses the impact that arises when their representatives intend to carry out joint projects.
RESUMEN
En este trabajo se analizan dos culturas, la de los científicos que desarrollan su propio software y la de los ingenieros de software que desarrollan software científico, se describen algunos de los problemas que surgen cuando ambas culturas se unen para desarrollar software científico, y se analiza el choque que surge cuando sus representantes intentan llevar a cabo proyectos conjuntos.
© 2013 IAI. All rights reserved.
1. INTRODUCCIÓN
Una de las diferencias entre el desarrollo del software comercial y desarrollo de software científico reside en la complejidad de su dominio. La mayoría de ingenieros de software tienen cierta intuición sobre lo que se requiere, por ejemplo, de un sistema de reservas de vuelo, uno bancario o uno de nómina, pero pocos intuyen lo que se necesita, por ejemplo, para modelar un sistema estocástico, uno de química cuántica o uno de cristalografía de proteínas. La implicación de esto es que los científicos necesitan estar profundamente involucrados en el desarrollo del sistema, o interpretar ellos mismos el rol de desarrolladores profesionales, o suministrar y explicar los requisitos, a la vez que retroalimentan y realizan pruebas de aceptación de usuario final en los productos software que requieren.
Para una mayor comprensión del objetivo de este trabajo es necesario definir los términos desarrolladores
profesionales y cultura. El primero se refiere a los científicos y a los ingenieros que trabajan en campos muy técnicos, que tienen amplio conocimiento de un dominio, y que desarrollan software con el fin de alcanzar sus propios objetivos profesionales y/o los de sus colegas más cercanos [1]; también se incluye a otros desarrolladores que no se consideran a sí mismos
desarrolladores de software, que tienen poca o ninguna formación en Ingeniería de Software, y que contrario a la mayoría de desarrolladores la codificación per se les presenta algunos problemas, porque están acostumbrados a desarrollar en lenguajes formales. El término cultura en sí tiene muchos significados, pero en este artículo se toma como una referencia al conjunto de valores y comportamientos habituales de un grupo identificable de personas, que para esta investigación son los desarrolladores profesionales y los ingenieros de software.
RACCIS, 3(1), 19-24, 2013
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
20 Este documento se basa en estudios de campo realizados
con grupos matemáticos financieros, científicos planetarios y de la tierra, científicos espaciales y biólogos moleculares. En el contenido se describe la cultura dentro de la cual se inscriben los científicos que desarrollan software por su propio uso y/o para sus colegas más cercanos, y se presenta el modelo que emplean para desarrollar sus productos. Posteriormente se detallan algunos problemas que tienen los ingenieros de software cuando trabajan en estrecha colaboración con los científicos para desarrollar software científico, y que se originan a partir del desajuste cultural que se presenta en el equipo. En el primer caso, los ingenieros tratan de imponer la cultura tradicional de la Ingeniería de Software, y en el segundo, los científicos esperan que los ingenieros adopten la cultura del desarrollo profesional. También se discuten las limitaciones de los estudios de campo, porque a pesar de que exploran una amplia variedad de contextos, de ninguna manera se pueden considerar exhaustivos. Además, se analiza si modelos de desarrollo como el de cascada o el incremental se ajustan mejor al software científico, y si las características de la cultura que se describen son comunes en todos los contextos de desarrollo de software científico.
2. LAS DOS CULTURAS 2.1 Valores
La característica más sobresaliente de la cultura de los desarrolladores profesionales, observada en los estudios de campo con los matemáticos y los científicos de la tierra y el espacio, es el escaso valor atribuido a los conocimientos necesarios para desarrollar software, en comparación con la apreciación del conocimiento del dominio matemático/científico [1]. Estas personas se expresan en términos como que todo el mundo sabe cómo desarrollar software, que dicho conocimiento es simplemente parte de la armería del científico promedio, y que un componente software es algo que se puede construir en una hora de almuerzo.
En los contextos formativos de estos científicos, el desarrollo de software es algo que se practica al inicio de sus carreras profesionales. A medida que ascienden en el escalafón profesional, van dejando atrás esta actividad para que la realicen los jóvenes. La situación, en la que este no es el caso, es decir, en la que un desarrollador profesional o un ingeniero de software que trabaja en una organización desarrollando software a tiempo completo, no parece diferir significativamente en lo que tiene que ver con el bajo valor que la misma organización le da a los conocimientos y habilidades necesarias para hacerlo. Los biólogos moleculares, aunque la automatización es clave para su trabajo de laboratorio, y por supuesto el software es clave para lograrla, sienten que desarrollando software no podrán llegar a ser jefes del laboratorio. Su creencia es que a esa posición siempre llegan biólogos tradicionales, a pesar de que la biología tradicional juega una parte relativamente pequeña en el trabajo de laboratorio.
De acuerdo con la opinión de los ingenieros de software que están vinculados con centros de investigación,
gubernamentales o privados, los desarrolladores no logran fácilmente los ascensos debido a que debe mantener una publicación científica constante para lograrlo. Esto a pesar del hecho de que su competencia es el desarrollo de software y no la de escribir artículos científicos. Además, consideran que su labor no es adecuadamente comprendida, y que no se puede juzgar al desarrollo de software profesional como si fuera una labor rutinaria para la organización. Porque los criterios de calidad que el producto necesita involucran, en muchas ocasiones, vidas humanas, a diferencia del trabajo que realizan muchos otros científicos, donde lo más preocupante es que entreguen datos incorrectos y vean lesionada su imagen y credibilidad.
Ese bajo valor atribuido a los conocimientos y habilidades sin duda contribuye a las dificultades que los desarrolladores profesionales tienen para adquirirlas [1], a pesar de que se supone que todo el mundo sabe lo que debe hacer. Los desarrolladores profesionales rara vez han tenido una formación adecuada en Ingeniería de Software, sin embargo, lo mismo se puede decir de muchos ingenieros de software; y de hecho, frecuentemente muchos cursos universitarios en esta área son impopulares entre los potenciales desarrolladores profesionales, porque a menudo se les imparten de forma independiente del dominio, y los estudiantes son incapaces de establecer vínculos entre la manera como se forma en Ingeniería de Software y la ciencia que han elegido [2].
Una cuestión importante para una adecuada formación son los procesos formativos soportados en la resolución de problemas y en las prácticas continuas. En el trabajo de campo se encontró que los ingenieros de software adquieren conocimientos y habilidades a través de una variedad de medios, pero que todos dependen de comunidades o redes en la que se practica el desarrollo de programas. Estos procesos incluyen el trabajo con una variedad de otros desarrolladores, en una diversidad de proyectos y compartiendo conocimientos de manera informal, lecturas de libros y estudio de tutoriales, atendiendo recomendaciones de los colegas, y asistiendo a conferencias técnicas y cursos de corta duración, y los productos se dan a conocer para discusión práctica en la red. Para los desarrolladores profesionales no existen estas comunidades, porque los procesos se desenvuelven en el dominio de aplicación, es decir, la ciencia. Además, suelen trabajar solos o en grupos muy pequeños y rara vez tienen la oportunidad de compartir conocimientos de manera informal. En al menos uno de los estudios de campo se encontró la percepción de que el conocimiento para el desarrollo de software es trivial y conocido por todos, lo que significa que la coordinación es reacia a gastar dinero en recursos como cursos diseñados para mejorar ese conocimiento.
2.2 Comportamientos
21 Figura 1. Modelo de desarrollo de los científicos [3]
En este modelo, el desarrollador comienza con una idea vaga de lo que se necesita, desarrolla rápidamente un componente software, y luego se sienta y reflexiona acerca de si el producto hace lo que necesita y en cómo ampliarlo o modificarlo; en algunos casos consultado a sus colegas. Realiza y evalúa varias veces este proceso hasta que decide que tiene una versión adecuada. No tiene en cuenta las pruebas o ejecuta casos muy superficiales; por ejemplo, introduce algunos tipos de datos similares a los que se pueden aparecer cuando se libere el producto, y comprueba la salida para ver si es correcta, o al menos que se acerque a lo esperado. Entonces, el software está listo para ser liberado como una herramienta para uso científico.
Las características principales de este modelo son: 1) falta de un modelo inicial de requisitos, 2) entrelazamiento de la evaluación y la identificación de las necesidades emergentes y 3) carácter superficial de la prueba final. Este patrón no se trabaja en los cursos de Ingeniería de Software, sin embargo, a juzgar por su omnipresencia, funciona, aunque en el contexto parte de una idea vaga de lo que se necesita y depende de que el desarrollador tenga un conocimiento suficiente y amplio del dominio.
La confianza en la retroalimentación obedece a que el desarrollador esté involucrado en la comunidad de usuarios. En la mayoría de proyectos software se tiene problemas para lograr que los potenciales usuarios participen en el proceso de desarrollo ofreciendo sus opiniones y aportando en la construcción. Conseguir tal retroalimentación es mucho más fácil si el usuario, como desarrollador, les pide a sus colegas la opinión sobre el producto.
En cuanto a la superficialidad de las pruebas se puede decir lo siguiente: 1) el escaso valor asignado al software en relación con el colocado a la ciencia: el software se valora sólo en la medida en que avanza la ciencia. Aquí es necesario que los científicos consideren al software de la misma manera que a cualquier otro instrumento que les permite lograr sus esfuerzos científicos. Filósofos e historiadores de la ciencia [4] afirman que los científicos asumen que sus instrumentos funcionan sólo cuando los
confrontan con pruebas absolutamente incontrovertibles. Tal vez esta hipótesis también se cumple para su software: la calidad innata del software no se cuestiona a menos que quede claro que no está apoyando la ciencia. 2) El hecho de que el desarrollador esté involucrado en la comunidad de usuarios: si un científico encuentra fallas en un componente software de un colega tiene la ventaja de que hacen parte de la misma comunidad, y las modificaciones las puede implementar con facilidad. 3) La dificultad para validar un producto en el que el dominio es poco conocido: tiene que ver con la naturaleza del software científico, y se refiere a que su finalidad es poder avanzar en la comprensión del mismo dominio [5]. En este caso, simplemente no hay forma de que los científicos puedan saber si la salida del software es correcta: sólo tienen que confiar en sus instintos de que la salida no es absolutamente incorrecta.
3. CHOQUE DE CULTURAS
En esta sección se describen dos situaciones: 1) los ingenieros de software tratan de imponerles a los científicos la cultura tradicional de la Ingeniería de Software y 2) los científicos asumen que los ingenieros de software están trabajando dentro de la cultura del modelo de desarrollo de software científico.
3.1 Por qué los científicos no pueden ser más como ingenieros de software
22 siguieron un modelo de desarrollo tipo cascada
escalonada, de acuerdo con lo recomendado por la European Space Agency (ESA). Los científicos en el laboratorio siguieron el modelo de desarrollo de la Figura 1. El primer problema que surgió fue el de los requisitos,
tal como se ilustra en la Figura 2. Los ingenieros necesitaban un documento de especificación, mientras que los científicos esperaban que la mayoría de requisitos emergieran en el proceso.
Figura 2. Por qué los científicos no pueden ser más como ingenieros de software [3]
3.2 Por qué los ingenieros de software no pueden ser más como científicos
Este análisis se basa en aspectos de un estudio de campo inédito en el que unos biólogos moleculares emplearon a ingenieros de software para escribir algunos programas para la comunidad. Los biólogos habían sido todos alguna vez desarrolladores profesionales, y algunos todavía estaban desarrollando su propio software. Sin embargo, la comunidad para la que estaba destinado el software era diversa y el producto en sí era mucho más grande que cualquiera que un desarrollador profesional hubiese
abordado, por lo tanto se consideró necesario que los científicos emplearan a los ingenieros de software.
El primer problema que enfrentaron fue, nuevamente, los requisitos. Al entregarle al director del proyecto de los ingenieros una lista de características, los biólogos indicaron verbalmente que los requisitos se conocían con exactitud y que ahí estaban. Por supuesto, la descripción estaba en un lenguaje demasiado alto como para que los ingenieros la pudieran aplicar. En la Figura 3 se ilustra un ejemplo hipotético de esta situación, aunque muy cercana a la realidad.
Figura 3. Por qué los ingenieros de software no pueden ser más como científicos
El proceso que aplican los científicos para escribir un componente de software con una determinada funcionalidad científica es perfectamente razonable, siempre que el desarrollador sea un científico. En este caso, el desarrollador conoce el dominio, tiene alguna intuición acerca de cómo puede funcionar y puede utilizar un programa de adaptación gráfica simple, puede desarrollar un primer prototipo y pedirles a sus colegas que lo revisen, y generalmente sigue el modelo de desarrollo de la Figura 1. El ingeniero de software, sin
embargo, con una, aunque sea débil, comprensión del dominio, tiene grandes dificultades para continuar.
23 1. Los requisitos. Para el desarrollador profesional la
elicitación de requisitos está totalmente integrada con el desarrollo mismo, como se ilustra en la Figura 1; además, en el contexto en el que se desenvuelve es un fiel representante del grupo de usuarios finales, lo que implica que el grupo es homogéneo y no se divide en subgrupos con objetivos y comportamientos diversos. Para el ingeniero de software, que desarrolla para una comunidad diversa, la elicitación de requisitos es una tarea que le consume tiempo y es difícil. Los usuarios potenciales tienen que ser persuadidos para desvincularse de sus tareas y comprometerse con el desarrollo de un sistema, que posiblemente nunca utilizarán cuando esté finalizado. Los ingenieros de software tienen que asegurar que la diversidad de la comunidad de usuarios esté representada adecuadamente, que los enfrentamientos entre los diferentes sectores de la misma se resuelvan, y así sucesivamente.
2. Aquellas cuestiones que reflejan los valores de la ingeniería de software, en comparación con los de los desarrolladores profesionales. Una de ellas es la prueba. Previamente se discutió que la prueba superficial es una característica del modelo de los desarrolladores profesionales, en parte porque se hace énfasis en la ciencia que el producto está destinado a apoyar y no en el software per se. Por otro lado, para los ingenieros de software lo ideal sería identificar los objetivos de calidad para cualquier componente software, y asignar el tiempo de prueba de acuerdo con ellos. Por ejemplo, un objetivo de calidad podría ser la robustez, en cuyo caso se debe destinar tiempo suficiente a las pruebas de tal forma que el producto responda sin importar la variedad de entradas. Otras cuestiones que no suelen tener mayor impacto para los desarrolladores profesionales es la portabilidad y la facilidad de mantenimiento. También puede haber problemas de seguridad cuando se trata de una comunidad de usuarios diversos, por ejemplo, los problemas de acceso a los datos cuando varios usuarios utilizan a la vez el mismo sistema.
4. LIMITACIONES DE LA INVESTIGACIÓN
Los estudios de campo presentados en este trabajo [1, 6] se desarrollaron en una amplia variedad de configuraciones; sus dominios de aplicación son las matemáticas financieras, las ciencias planetarias y la biología molecular, en los que los científicos han desarrollado su software en colaboración con ingenieros de software o por su propia cuenta, los cuales incluyen aplicaciones para impulsar los instrumentos, los modelos de mercados financieros y para almacenar, analizar y apoyar la interpretación de datos. En esta variedad se encontró una serie de elementos comunes, como el escaso valor atribuido a los conocimientos y habilidades para desarrollar software en comparación con el conocimiento y habilidades en el dominio, y la ubicuidad del modelo aplicado por los desarrolladores profesionales.
Sin embargo, estos estudios de ninguna manera son integrales. Por ejemplo, los ingenieros de software en
ningún momento adoptaron metodologías ágiles, que de acuerdo con otros desarrolladores es un proceso iterativo de bucles de retroalimentación y de comunicación cara a cara [7], y que podrían ofrecer más al desarrollo de software científico que los métodos tradicionales por etapas de tipo cascada. En la literatura se encuentran informes de experiencias de ingenieros de software que han participado con éxito en el desarrollo ágil científico [8, 9]. Sin embargo, para este trabajo no se encontraron datos de estudios de campo con objetivos en las áreas tratadas, y dados los resultados de los trabajos analizados en desarrollo de software científico, surge el interrogante de si cuando los científicos se refieren a sí mismos como que aplican una metodología ágil, se están refiriendo al modelo de retroalimentación iterativa de la Figura 1.
Además, los estudios de campo tratados aquí no cubren los sistemas de alto rendimiento (HPCS por sus siglas en inglés), es decir, sistemas en los que varios procesadores actúan en paralelo. Estos sistemas son de uso común en la ciencia para simular fenómenos naturales que son demasiado grandes, o demasiado pequeños, o demasiado peligrosos, o demasiado complejos, para ser investigados en vivo. Recientemente, en los EE.UU. se ha incrementado el interés por la investigación en HPCS, impulsado por grandes proyectos múltiple-fases, como el DARPA [10]. Este proyecto se inició como respuesta a la preocupación de que la productividad científica, usando sistemas HPCS, no parecía progresar a la velocidad que mejoran las capacidades hardware. El objetivo es mejorar la productividad científica en un factor de diez, a fuerza de mejorar el software y el hardware. Sin embargo, la naturaleza exacta del concepto de productividad científica
no parece haber sido explicado completamente.
DARPA ha generado varios estudios de campo de los científicos que están profundamente involucrados en el desarrollo de simulaciones software [5, 11]. Los contextos en que los científicos utilizan HPCS son variados y algunos aceptan que sus estudios no son exhaustivos [11]. También reconocen que, incluso dentro de sus estudios de campo, se encontraron con gran cantidad de variaciones. Sin embargo, esos estudios de campo demuestran similitudes con el trabajo que aquí se presenta. Por ejemplo, encontraron que para la ciencia el software era de suma importancia, que el proceso aplicado tiene una dependencia directa de los requisitos emergentes, y que en todos tienen dificultades con las pruebas.
24 explicación es que estos científicos consideran que la
física tiene esencialmente tres ramas de igual valor: la teórica, la experimental y la in silico ―simulaciones
software―. Este no parece ser el caso de estudios de
campo analizados en esta investigación, porque el software, a excepción de los matemáticos financieros, se ve como una herramienta de apoyo a la investigación científica y no como un modelo de ciencia que se puede consultar directamente. Dada la importancia de las simulaciones en la ciencia, es evidente que los HPCS representan un dominio del desarrollo de software científico que representa un área de trabajo futuro.
5. CONCLUSIONES
En los estudios de campo analizados se identificaron dos características de la cultura de los científicos desarrolladores profesionales: 1) el bajo valor que se da al conocimiento y habilidades para el desarrollo de software, en comparación con el conocimiento del dominio, y 2) un modelo de desarrollo profesional. A juzgar por su omnipresencia, este último es un gran éxito, aunque sólo en un contexto particular. Para este contenido se identificaron las siguientes características:
El desarrollador se inserta en la comunidad de usuarios
La comunidad de usuarios es coherente
Los requisitos no están plenamente establecidas desde el principio
El valor del software reside en la medida en que progresa la ciencia
Otra cuestión que llama la atención en esta investigación son los enfrentamientos que se producen cuando los ingenieros de software tratan de imponer a los científicos su cultura de desarrollo tradicional, y viceversa.
La cobertura de los estudios de campo analizados ilustra sólo algunas de las variedades de desarrollo de software científico. Otros estudios de campo han investigado la situación en la que se desarrollan sistemas de computación de alto rendimiento para fines de simulación, y han confirmado que en ellos prima la ciencia sobre el software, la importancia de los requisitos emergentes y las dificultades de las pruebas.
Esta investigación es importante porque se demuestra que los ingenieros de software no pueden esperar proporcionar herramientas, tecnologías y métodos eficaces para mejorar el desarrollo de software científico sino comprenden el contexto cultural, los valores y los comportamientos habituales, en los que este desarrollo tiene lugar. La falta de comprensión de este contexto puede generar importantes problemas en el proceso, pero todavía hay mucho trabajo por hacer en este campo. Por ejemplo, un programa de investigación completo podría abarcar lo siguiente:
1. Identificar las dimensiones sobresalientes en las que se pueden caracterizar contextos de computación científica. Esto podría incluir: si los científicos están
desarrollando el software por su cuenta, y si no, el grado en que los ingenieros de software están implicados, y el valor atribuido al desarrollo de software en la comunidad de usuarios. Otras dimensiones pueden ser: si la comunidad de usuarios es homogénea o diversa, el tamaño del equipo de desarrollo, la longevidad del código, entre otras tantas.
2. Identificar aquellas técnicas de ingeniería de software establecidas que podrían ayudar a los desarrolladores de software científico.
3. Establecer una correlación entre las técnicas de software identificadas en ambas culturas y los contextos caracterizados por las dimensiones de los desarrolladores profesionales y la cultura.
4. Identificar los medios por los que los científicos podrían estar al tanto de las técnicas y herramientas de ingeniería de software que pueden ser relevantes para sus desarrollos.
Este último punto es especialmente importante dadas las dificultades de intercambio de conocimientos entre los desarrolladores profesionales. Esta agenda de investigación puede parecer desalentadora, pero se espera que este trabajo y otros similares puedan contribuir a un importante primer paso.
6. REFERENCIAS
[1] Segal, J. (2007). Some problems of professional end user developers. In proceedings IEEE Symposium on Visual Languages and Human-Centric Computing, VLHCC’07 (Idaho, USA, September 23-27), pp. 111-118.
[2] Kelly, D.F. (2007). A software chasm: software engineering and scientific computing. IEEE Software, 24(6), pp. 120-199.
[3] Segal, J. & Morris, C. (2008). Developing scientific software. IEEE Software, 25(4), pp. 18-20.
[4] Chalmers, A.F. (1999). What is this thing called science?
Hackett; Edición: 3.
[5] Carver, J.C. et al. (2007). Software Development Environments for Scientific and Engineering Software: A Series of Case Studies. In proceedings Int’l Conf. Software Engineering, CSE’07 (Minneapolis, USA, May 19-27), pp. 550-559.
[6] Segal, J. (2005). When software engineers met research scientists: a case study. Empirical Software Engineering, 10(4), pp. 517-536.
[7] http://agilemanifesto.org/ [Jan. 2013].
[8] Bache, E. (2003). Building software for scientists: a report about incremental adoption of XP. In proceedings 4th International Conference, XP2003 (Genoa, Italy, May 25-29), pp. 24.
[9] Kane, D. (2003). Introducing agile development into bioinformatics: an experience report. In proceedings Agile Development Conference, ADC2003 (Salt Lake City, USA, June 25-28), pp. 132-139.
[10] www.highproductivity.org [Jan. 2013].
[11] Basili, V.R et al. (2008). Understanding the high
performance computing community: a software engineer’s
![Figura 2. Por qué los científicos no pueden ser más como ingenieros de software [3]](https://thumb-eu.123doks.com/thumbv2/123dok_br/18370011.355185/4.892.213.688.192.441/figura-científicos-pueden-ser-ingenieros-software.webp)
