videos uso tutorial sobre que proyectos para gestion español ejemplos curso workflow bioinformatics

workflow - uso - ¿La mejor manera de organizar proyectos bioinformáticos?



video uso trello (5)

Para respuestas específicas de bioinformática, es probable que esté interesado en estas dos preguntas sobre BioStar (el sitio de bioinformática StackExchange 1.0)

Vengo de una informática. De fondo, pero ahora estoy haciendo genómica.

Mis proyectos incluyen una gran cantidad de bioinformática que generalmente incluyen: alinear secuencias, comparar superposiciones, etc. entre secuencias y varias características de anotación del genoma, de diferentes clases de muestras biológicas, datos de cursos de tiempo, microarray , secuenciación de alto rendimiento ( "next- secuenciación de "generación" , aunque en realidad es la generación actual) 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: no hay objetos UML y diseñados cuidadosamente que brillen con una elegancia sublime, ni gestión de versiones, ni documentación adecuada (a menudo sin documentación), sin ingeniería de software en todos.

En su lugar, lo que todo el mundo hace en este campo es hackear un script Perl o AWK una línea después del otro, generalmente para 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 quiere escribir un trazador de rayos. Probablemente primero pondría mucho esfuerzo en la ingeniería de software. Luego programalo, finalmente en alguna forma altamente optimizada. Debido a que usaría el trazador de rayos innumerables veces con diferentes datos de entrada y haría cambios en el código fuente durante los próximos años. Por lo tanto, una buena ingeniería de software es primordial cuando se codifica un trazador de rayos serio desde cero. Pero imagine que desea escribir un trazador de rayos, donde ya sabe que lo usará para trazar un solo rayo, una sola imagen. Y esa imagen es de una esfera reflectante sobre un suelo a cuadros. En este caso, simplemente lo hackearían de alguna manera. La bioinformática es como el último caso solamente.

Terminará con árboles de directorios completos con la misma información en diferentes formatos hasta que haya alcanzado el formato particular necesario para el siguiente paso, y una docena de archivos con nombres como "tmp_SNP_cancer_34521_unique_IDs_not_Chimp.csv" donde no tiene la más mínima idea. Un día después, por qué creaste este archivo y qué es exactamente.

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

Soy consciente de una publicación única que trata estos temas (Noble, WS (2009, julio). Una guía rápida para organizar proyectos de biología computacional. PLoS Comput Biol 5 (7), e1000424 +). El autor resume el objetivo bastante bien:

El principio guía básico es simple: alguien que no esté familiarizado con su proyecto debería poder mirar los archivos de su computadora y comprender en detalle lo que hizo y por qué.

Bueno, eso es lo que quiero, también! Pero ya estoy siguiendo las mismas prácticas que ese autor, y siento que es absolutamente insuficiente.

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

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

¿Cómo organizas tus proyectos de bioinformática?

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

Para el diseño de desarrollo de software (y 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 encarecidamente 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 múltiples tareas mientras se ejecutan análisis largos.

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á resolviendo problemas con los datos) y cuáles son los resultados y los 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 confío al repositorio. En la medida de lo posible, trato de nombrar salidas de datos de una manera que pueda colocar en mi git ignorar archivos. Luego, en la medida de lo posible, trabajo en una sola sesión de terminal para un proyecto a la vez, y cuando llego a un punto de pausa (como cuando tengo un conjunto de trabajos enviados a la red, ejecuto el historial | corte -c 8- ''y péguelo en un archivo de notas de laboratorio. Luego edito el archivo para agregar comentarios a lo que hice, y recuerde, cambie las líneas git add / commit para 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 recrear todo el proceso más adelante.

Para cualquier tarea de procesamiento incluso un poco compleja, escribo un script para hacerlo, de modo que mi portátil, en la medida de lo posible, se vea limpio. En una aproximación, un script de ayuda puede verse como una subrutina en un proyecto más grande, y debe documentarse internamente al menos en ese nivel.

Soy un especialista en software integrado en un equipo de científicos de investigación, aunque en ciencias de la tierra, no en 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 aprendió en sus estudios se trata de software de ingeniería para uso continuo. Como usted ha observado mucho de lo que hacen los científicos de investigación es sobre el uso único y el enfoque de ingeniería no es adecuado. Si desea implementar algunos aspectos de una buena ingeniería de software, tendrá que elegir sus batallas con cuidado.

Antes de comenzar a librar batallas, tendrá que examinar críticamente sus propias ideas para asegurarse de que lo que aprendió en la escuela sobre ingeniería de software de propósito general sea válido para su situación actual. No asuma que lo es.

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

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

Una vez que reuní la información, y me aseguro de mantener buenas notas sobre quién dijo qué y cuánto les costó, se hizo relativamente fácil pintar una imagen de un mundo mejor con el control del código fuente.

A continuación, bueno, luego tienes que elegir tu propia batalla. Pero una de las semillas de la duda que tienes que sembrar en la mente de tus científicos y colegas 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.

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

Acerca de la presión ... Nuevamente, hay otros en este mundo que tienen fechas límite muy exigentes, y todavía están usando 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, con su pregunta real ... Puede ofrecerle a su administrador que rediseñe pequeñas partes del código que no influyen en el resto del código como prueba de concepto (POC), pero es realmente difícil evitar que un camión se mantenga moviéndose, así que no se enoje si se siente "trabajamos de esta manera durante años, sabemos lo que estamos haciendo y no necesitamos que un niño nos enseñe cómo hacer nuestro trabajo". Aprende a trabajar como el resto y cuando ganes su confianza, podrías hacer lo tuyo de vez en cuando (espero que tengas tiempo y la dedicación para hacer lo correcto).

Buena suerte.