2010-09-21 11 views
19

Vengo de una ciencia de la computación. antecedentes, pero ahora estoy haciendo genómica.¿La mejor manera de organizar proyectos de bioinformática?

Mis proyectos incluyen una gran cantidad de bioinformática que implica típicamente: alineación de secuencias, comparación de superposición, etc. entre secuencias y diversas características de anotación genómica, de diferentes clases de muestras biológicas, datos de curso de tiempo, microarray, secuenciación de alto rendimiento ("next-generation" sequencing, aunque es la generación actual en realidad) datos, este tipo de cosas.

El flujo de trabajo con este tipo de análisis es bastante diferente de lo que experimenté durante mis estudios de informática: ningún UML y objetos cuidadosamente diseñados que brillan con elegancia sublime, sin gestión de versiones, sin documentación adecuada (a menudo sin documentación) no hay ingeniería de software en absoluto.

En su lugar, lo que hace todo el mundo en este campo es la piratería a cabo una Perl script o AWK -una sola línea después de la otra, por lo general para el uso de una sola vez.

Creo que la razón es que los datos de entrada y los formatos cambian tan rápido, las preguntas deben responderse tan pronto (¡plazos!) Que parece que no hay tiempo para la organización del proyecto.

Un ejemplo para ilustrar esto: Digamos que desea escribir un raytracer. Probablemente pondría mucho esfuerzo en la ingeniería de software primero. Luego, programémoslo, finalmente en una forma altamente optimizada. Debido a que utilizaría el raytracer innumerables veces con diferentes datos de entrada y haría cambios en el código fuente durante los próximos años. Entonces, una buena ingeniería de software es primordial cuando se codifica un raytracer serio desde cero. Pero imagina que quieres escribir un raytracer, donde ya sabes que lo usarás para rastrear una sola imagen. Y esa imagen es de una esfera reflectante sobre un piso a cuadros. En este caso, lo piratearías de alguna manera. La bioinformática es como el último caso solamente.

Se termina con el árbol de directorios con la misma información en diferentes formatos hasta que haya alcanzado un determinado formato necesario para el siguiente paso, y docenas de archivos con nombres como "tmp_SNP_cancer_34521_unique_IDs_not_Chimp.csv" en el que no tiene la idea más leve un día después de por qué creó este archivo y qué es exactamente.

Por un tiempo estaba usando MySQL lo que me ayudó, pero ahora la velocidad con la que se generan nuevos datos y los formatos de cambios es tal que no es posible hacer un diseño de base de datos adecuado.

Conozco una publicación única que trata estos temas (Noble, W. S. (2009, julio). Una guía rápida para organizar proyectos de biología computacional. PLoS Comput Biol 5 (7), e1000424 +). Las sumas autor del gol bastante bien:

El núcleo principio rector es simple: alguien no familiarizado con su proyecto debe ser capaz de mirar a sus archivos de computadora y entender en detalle lo que hizo y por qué.

¡Bueno, eso es lo que quiero, también! Pero sigo las mismas prácticas que ese autor, y creo que es absolutamente insuficiente.

Documentar todos y cada uno de los comandos que emite en Bash, comentándolo exactamente por qué lo hizo, etc., es simplemente tedioso y propenso a errores. Los pasos durante el flujo de trabajo son muy finos.Incluso si lo hace, puede ser una tarea extremadamente tediosa averiguar para qué era cada archivo, y en qué momento se interrumpió un flujo de trabajo particular, y por qué motivo, y dónde continuó.

(No estoy usando la palabra "flujo de trabajo" en el sentido de Taverna, me refiero solo a los pasos, comandos y programas que elige ejecutar para alcanzar un objetivo en particular).

¿Cómo organiza sus proyectos de bioinformática?

+0

Mi pregunta es: ¿cómo hacer que * * => Wiki de la Comunidad – fredley

+1

excelente pregunta . No he encontrado una respuesta satisfactoria para esto yo mismo. ¡Espero las respuestas! – pufferfish

Respuesta

11

Soy un especialista en software integrado en un equipo de científicos investigadores, aunque en las ciencias de la tierra, no en las ciencias de la vida. Mucho de lo que escribes me es familiar.

Una cosa a tener en cuenta es que gran parte de lo que ha aprendido en sus estudios se trata de software de ingeniería para su uso continuado. Como ya ha observado, gran parte de lo que hacen los científicos investigadores es sobre el uso de una sola vez y el enfoque diseñado no es adecuado. Si desea implementar algunos aspectos de una buena ingeniería de software, tendrá que elegir cuidadosamente sus batallas.

Antes de comenzar a luchar en cualquier batalla, tendrá que examinar críticamente sus propias ideas para asegurarse de que lo que aprendió en la escuela sobre ingeniería de software de uso general sea válido para su situación actual. No supongas que lo es.

En mi caso, la primera batalla que elegí fue la implementación del control del código fuente.No fue difícil encontrar ejemplos de todas las cosas que van mal cuando no tiene el control de versiones en su lugar:

  • algunos usuarios tenían docenas de directorios, cada uno con diferentes versiones del 'mismo' código, y solo la idea más opaca de lo que la mayoría de ellos hizo era única, o por qué estaban allí;
  • algunos usuarios habían perdido modificaciones útiles sobrescribiéndolas y no pudiendo recordar lo que habían hecho;
  • fue fácil encontrar situaciones en las que las personas estaban trabajando en lo que debería haber sido el mismo programa pero que de hecho se estaban desarrollando de manera incompatible en diferentes direcciones;
  • etc, etc, etc

Una vez que había reunido la información - y asegúrese de mantener buenas notas acerca de lo que dijo y lo que les costó - se hizo relativamente fácil de pintar un cuadro de un mundo mejor con control de código fuente.

A continuación, bueno, a continuación tienes que elegir tu próxima batalla. Pero una de las semillas de la duda que tienes que sembrar en la mente de tus colegas científicos es la "reproducibilidad". Los experimentos científicos no son válidos si no son reproducibles; si sus experimentos involucran software (y siempre lo hacen), una ingeniería de software cuidadosa es esencial para la reproducibilidad. Mucho de esto se trata de la procedencia de los datos, pero ese es un tema para otro día.

0

Su pregunta es acerca de la gestión de proyectos. La mala gestión de proyectos no es exclusiva de la bioinformática. Encuentro difícil de creer que toda la industria de la bioinformática esté comprometida con un mal diseño de software.

Sobre la presión ... De nuevo, hay otros en este mundo que tienen plazos muy desafiantes, y todavía usan buenos diseños de software.

En muchos casos, seguir un buen diseño de software no detiene los proyectos e incluso puede acelerar su diseño y mantenimiento (al menos a largo plazo).

Ahora a su pregunta real ... Puede ofrecerle a su gerente rediseñar partes pequeñas del código que no tienen influencia sobre el resto del código como prueba de concepto (POC), pero es realmente difícil detener una camión de seguir en movimiento, así que no se enfade si siente que "trabajamos de esta manera durante años, sabemos lo que estamos haciendo y no necesitamos un niño que nos enseñe cómo hacer nuestro trabajo". Aprenda a trabajar como el resto y cuando gane su confianza, podría hacer su trabajo de vez en cuando (espero que tenga tiempo y la dedicación para hacer lo correcto).

Buena suerte.

1

Parte del problema aquí es la distinción entre documentación para software vs documentación para publicación.

Para el diseño de desarrollo de software (y el plan de investigación), la documentación importante es estructural e intencional. Por lo tanto, modelar los datos, las razones por las que está haciendo algo, etc. Recomiendo utilizar las habilidades que ha aprendido en CS para documentar su plan de investigación. Tener un plan para lo que quiere hacer le da mucha libertad para realizar tareas múltiples mientras se ejecutan largos análisis.

Por otro lado, una gran cantidad de trabajo de bioinformática es el análisis. Aquí, debe tratar la documentación como un cuaderno de laboratorio, y no necesariamente un plan de proyecto. Desea documentar lo que hizo, tal vez un breve comentario sobre por qué (por ejemplo, cuando está solucionando datos) y cuáles son los resultados y resultados. Lo que hago es bastante simple. Primero, comienzo en un directorio y creo un repositorio git. Luego, cada vez que cambio algún archivo, lo comprometo con el repositorio. En la medida de lo posible, trato de nombrar las salidas de datos de una manera que pueda incluir en mi git, ignorar los archivos. Luego, en la medida de lo posible, trabajo en una sola sesión de terminal para un proyecto a la vez, y cuando toco un punto de pausa (como cuando tengo un conjunto de trabajos enviados a la cuadrícula, ejecuto 'historial | cortar -c 8- 'y pegar eso en un archivo de notas de laboratorio. Luego edito el archivo para agregar comentarios para lo que hice, y recuerdo, cambiar las líneas de agregar/confirmar de git a git checkout (tengo un script que hace esto basado en los mensajes de confirmación). Siempre que lo inicie en el directorio correcto y mis datos externos no desaparezcan, esto significa que puedo volver a crear todo el proceso más adelante.

Para tareas de procesamiento incluso ligeramente complejas, escribo un script para hacerlo, de modo que mi portátil, tanto como sea posible, se vea limpio. Para una aproximación, un script auxiliar puede verse como una subrutina en un proyecto más grande, y debe documentarse internamente al menos en ese nivel.

Cuestiones relacionadas