Estructura para trabajo de investigación en informática.

Estoy escribiendo mi primer trabajo de investigación de licenciatura en informática y creo que mi falta de experiencia está empezando a poner nervioso a mi supervisor. He escrito un programa que recopila metadatos de video e intenta organizar videos en una secuencia coherente usando los metadatos. El programa también ha sido probado por un panel de usuarios.

El supervisor me ha dado las siguientes secciones para trabajar:

  1. Introducción

  2. Fondo

    • tal vez subsecciones sobre diferentes áreas de fondo
  3. El enfoque
    3.1. Enfoque general
    3.2. Diseño detallado

  4. Decisiones clave de implementación

  5. Experimentos

  6. Trabajo relacionado

  7. Conclusiones

Estoy tratando de entender la diferencia entre (3) y (4) en el contexto de lo que estoy haciendo. Específicamente, ¿en qué se diferencia un diseño detallado de las decisiones de implementación?

Bienvenido a Escritores SE. Las preguntas aquí deben ser útiles para los demás; lamentablemente, esto está demasiado localizado. Podríamos ayudarlo con preguntas de estructura general ("¿Cómo puedo hacer que una introducción sea diferente de una conclusión?"), pero aquí nos está pidiendo consejo sobre su artículo en particular, lo que no ayudará a nadie que no esté escribiendo su artículo.
No es necesario que esté en el contexto de este artículo en particular. Las secciones que me ha dado son genéricas y solo estoy tratando de averiguar cómo 3.2 es diferente de 4. Supuse que sería más fácil de explicar en algún contexto.
Hola James y bienvenido a Writers.SE. Como dijo Lauren, esto está un poco localizado, pero para tratar de ayudarlo incluso si esta pregunta se cierra: lo que quiero decir con esa distinción si escribo o asigno el papel es que 3 es "lo que hiciste" y 4 es " qué decisiones clave te llevaron a hacer eso". No desea desordenar una discusión de metodología con todos esos detalles de "por qué", pero tampoco quiere dejarlos caer.
"Específicamente, ¿en qué se diferencia un diseño detallado de las decisiones de implementación?" Esta parte de la pregunta tiene respuesta, el resto es un poco confuso y difícil de precisar. ¿Quizás podamos editar esta pregunta para centrarnos un poco más en la parte responsable?
La respuesta de Maura a continuación es correcta. No importa cuán detallado sea su diseño, no tendrá dudas sobre las tecnologías reales utilizadas, etc. Mientras que la implementación es exactamente eso. Pero no creo que esta sea una pregunta de escritura, realmente; es una cuestión de desarrollo de software.

Respuestas (2)

El diseño incluiría cosas como "ordenar los datos por fecha" o "rastrear a cada autor de forma independiente".

La implementación sería cosas como un esquema de base de datos real o una rutina en sí misma.

La diferencia clave sería que el diseño es "lo que necesito hacer que suceda" y la implementación es "cómo hice que sucediera".

Dado el título "Decisiones clave de implementación", creo que la implementación debe ir más allá del 'cómo' y también explicar el 'por qué'. El diseño identifica el problema específico y da una idea de cómo solucionarlo. La implementación establece lo que realmente se ha hecho y por qué se tomaron esas decisiones (¿Por qué solo videos de gatos pero no de perros? ¿Por qué Chicago pero no Nueva York? etc.). A partir de ahí, puede pasar al experimento sobre una base sólida.

Agregando a la respuesta de Maura:

El " diseño detallado " implica que profundizarás mostrando la estructura abstracta de tu proyecto. Esto significa mostrar lo que hace el programa, sin mirar el código. Las decisiones de diseño deben discutirse y explicarse, a menudo con la ayuda de diagramas similares a UML, ya sea mostrando un diagrama de clases

diagrama de clases UML

o tal vez un proceso :ingrese la descripción de la imagen aquí

Esos por supuesto son ejemplos. Hay muchas cosas que se pueden hacer con UML en notación estandarizada: debe decidir cuál sería la más relevante según su programa. Si el código interactúa con servicios externos (por ejemplo, una base de datos, API web, Internet), puede valer la pena mostrar un diagrama arquitectónico.

En esta sección también puede describir cómo diseñó su método . Es un papel: implica que ha hecho su investigación. Por lo tanto, puede ser relevante mostrar aquí cómo diseñó el proceso de prueba.

" Decisiones clave de implementación " es donde se supone que debes mostrar que te ensuciaste las manos, como una forma de hablar. Aquí puede hablar sobre su código o cualquier mecanismo relacionado con la tecnología que haya utilizado en su investigación.

Tenga en cuenta que no necesita comentar todo: solo las partes "clave" que se requieren para comprender su programa. Nadie quiere leer un documento en el que describa cómo definió una matriz, ya que todos pueden hacerlo. Esencialmente, debe mostrar cómo implementó su diseño, qué tiene de interesante, qué hay de nuevo, qué es difícil y qué desafíos asumió.

Es posible que desee mostrar una parte "central" de su programa; es posible que desee analizar cómo decidió mejorar el rendimiento general mediante el uso de diferentes estructuras de datos durante el desarrollo; puede discutir por qué un método en particular le da mejores resultados, comentando el código. Esas son las "decisiones" que pertenecen a un papel.