¿Cómo se puede escribir una tesis en Ciencias de la Computación, sin realmente proporcionar la solución, sino investigarla y explicar cómo se está resolviendo en este momento, pero no para el problema específico (área de investigación) identificado por el investigador?
Por ejemplo, imagina que pasas tu primer año haciendo una revisión de la literatura sobre el tema.
Ahora, en su segundo año, se espera que cree esta solución, ¿qué sucede si no puede crearla o requiere demasiado código/tiempo/inversión? Obviamente, voy a tratar de construir la solución, pero ¿qué pasa si no la construyo, porque requerirá una gran cantidad de código y algoritmos avanzados?
¿Hay alguna manera de sobrevivir a eso? ¿Existen metodologías que se pueden usar cuando se ha realizado una revisión de la literatura y luego se ha intentado crear una solución que posiblemente haya fallado?
¿Cómo se puede continuar e investigar el tema, escribir la tesis o incluso publicar, sin tener todo el código para una solución? ¿Serán los gráficos/imágenes combinados con algún tipo de metodología una forma de realizar realmente esa investigación?
Mucha ansiedad y necesidad de ayuda, motivación y apoyo para saber cómo afrontar ese periodo en el que se requiere construir la solución.
Para una disertación doctoral (al principio me perdí la etiqueta), probablemente no haya salida. Sospecho que hay muy pocos programas de doctorado, en todo el mundo, que le darán un doctorado por un "intento fiel, pero fallido".
La solución es, lamentablemente, elegir un problema diferente, quizás relacionado con el original, pero que sea más susceptible de solución.
Sin embargo, si está haciendo una investigación "real" y no solo siguiendo los movimientos, no hay garantías. La investigación se trata de lo desconocido y lo desconocido puede ser difícil de revelar. Puede ser muy esquivo.
En mis días de tesis, trabajé en tres problemas (estilo de los tres osos). El primero era demasiado fácil y podía desarrollar un teorema y su demostración casi todos los días. Obtuve muchos resultados en unas pocas semanas, pero falló la prueba de significancia. Bonito, pero estaba abandonado. El segundo era demasiado duro y no podía rayar la superficie del revestimiento tipo diamante/titanio que me impedía el menor resultado. También abandonado.
El tercer problema era justo. Difícil, factible, significativo (para una audiencia muy pequeña, por supuesto). Pero si me hubiera golpeado la cabeza contra el segundo problema, probablemente todavía estaría allí casi cincuenta años después. (El estudiante de posgrado vivo más antiguo emerge de una cueva polvorienta para decir "no" una vez más).
Habla con tu asesor. Calcula una opción para un problema diferente. Sería bueno si estuviera lo suficientemente cerca del original para que su búsqueda bibliográfica le proporcione herramientas para el ataque. Pero no hay garantía. Lo desconocido es lo desconocido hasta que se vuelve conocido.
¿Hay alguna manera de sobrevivir a eso?
Sí hay. Daniel Hatton lo ha insinuado, pero lo elaboraré.
Durante su investigación, habrá muchas fallas y "sobrecostos de programación". Afortunadamente, esto se espera en la academia: después de todo, estás lidiando con lo desconocido. Sin embargo, si la parte en la que ha fallado ya la ha hecho alguien, rápidamente se vuelve mucho menos indulgente: se puede esperar que un doctorado en biología sea capaz de hacer la titulación, por caprichosos que sean los materiales, y se podría esperar un doctorado en CS. unir algo de código y escribir algo por su cuenta. Eso lo lleva a un territorio de "sin agallas, sin gloria": habrá que tomar algunos riesgos, y su experiencia pasada lo guiará a través de él. Es muy común tener subestimaciones y sobreestimaciones de la complejidad del problema en su carrera.
El truco aquí, por supuesto, es convertir los "fracasos" en "victorias". Relacionado: esto , esto , esto y esto .
Si bien se trata de grandes incógnitas en términos de estimaciones de tiempo, todavía se le paga por ello. Y se espera poder mostrar algunos resultados, de principio a fin. Eso significa buscar alternativas y tener siempre un plan B (C, D...) . ¿Escribir el código resultó ser demasiado difícil? ¿De qué otra forma podría mostrar el mérito de sus resultados? ¿Quizás en lugar del glorioso código de resolver todo, podría resolver un par de casos demasiado simplificados que facilitarían mucho la escritura del código relevante? ¿Tal vez podría hacer un trabajo analítico en su lugar (probablemente tomaría mucho más tiempo que escribir código, pero aún así)?
En pocas palabras, puede acortar su trabajo y no cubrir todo lo que se planeó originalmente, pero aún debe asegurarse de que su trabajo esté completo . Lo que esto significa en realidad es un enfoque bastante específico para la planificación en primer lugar: debe buscar estas salidas adicionales y no solo esperar recorrer la autopista de principio a fin en más o menos tiempo. El doctorado es, en gran parte, un ejercicio precisamente de eso.
El hombre
leucocitaria
daniel haton