Структура исследовательской работы по информатике

Я пишу свою первую исследовательскую работу по информатике для студентов и думаю, что мой недостаток опыта начинает действовать моему руководителю на нервы. Я написал программу, которая собирает метаданные видео и пытается организовать видео в связную последовательность, используя метаданные. Программа также была протестирована группой пользователей.

Руководитель дал мне следующие разделы для работы:

  1. Вступление

  2. Задний план

    • возможно, подразделы по разным областям фона
  3. Подход
    3.1. Общий подход
    3.2. Детальный дизайн

  4. Ключевые решения по внедрению

  5. Эксперименты

  6. Связанных с работой

  7. Выводы

Я пытаюсь понять разницу между (3) и (4) в контексте того, что я делаю. В частности, чем детальный проект отличается от решений по реализации?

Добро пожаловать в Writers SE. Вопросы здесь должны быть полезными для других; это, к сожалению, слишком локализовано. Мы могли бы помочь вам с общими вопросами по структуре («Как мне сделать введение отличным от заключения?»), но здесь вы спрашиваете нас о совете по вашей конкретной статье, что не поможет никому, кто не пишет вашу статью.
Это не должно быть в контексте этой конкретной статьи. Разделы, которые он мне дал, являются общими, и я просто пытаюсь понять, чем 3.2 отличается от 4. Я предположил, что это будет легче объяснить в каком-то контексте.
Привет, Джеймс, и добро пожаловать на Writers.SE. Как сказала Лорен, это немного локализовано, но чтобы попытаться помочь вам, даже если этот вопрос будет закрыт: я бы подразумевал под этим различием, что я пишу или назначаю работу, так это то, что 3 — это «то, что вы сделали», а 4 — это « какие ключевые решения привели вас к этому». Вы не хотите загромождать обсуждение методологии всеми этими подробностями «почему», но и не хотите отбрасывать их.
«В частности, чем детальный проект отличается от решений по реализации?» На эту часть вопроса можно ответить, остальное немного расплывчато и трудно определить. Может быть, мы можем отредактировать этот вопрос, чтобы немного больше сосредоточиться на ответной части?
Ответ Мауры ниже правильный. Каким бы подробным ни был ваш дизайн, вы не будете задаваться вопросами о реальных используемых технологиях и т. д. А реализация именно такова. Но я не думаю, что это письменный вопрос, на самом деле; это вопрос разработки программного обеспечения.

Ответы (2)

Дизайн будет включать такие вещи, как «упорядочить данные по дате» или «отслеживать каждого автора независимо».

Реализацией могут быть такие вещи, как реальная схема базы данных или сама подпрограмма.

Ключевое отличие будет заключаться в том, что дизайн — это «то, что мне нужно сделать», а реализация — «как я это сделал».

Учитывая заголовок «Ключевые решения по реализации», я думаю, что реализация должна выходить за рамки просто «как», а также объяснять «почему». Дизайн определяет конкретную проблему и дает представление о том, как ее решить. В реализации указывается, что на самом деле было сделано и почему были приняты эти решения (почему только видео с кошками, а не с собаками? почему Чикаго, а не Нью-Йорк? и так далее). Оттуда вы можете перейти к эксперименту на прочной основе.

Добавление к ответу Мауры:

« Детальный дизайн » подразумевает, что вы подробно продемонстрируете абстрактную структуру вашего проекта. Это означает показывать, что делает программа, не глядя на код. Проектные решения должны обсуждаться и объясняться, часто с помощью UML-подобных диаграмм, либо с отображением диаграммы классов

UML-диаграмма классов

или, может быть, процесс :введите описание изображения здесь

Это, конечно, примеры. Есть много вещей, которые можно сделать с UML в стандартизированной нотации — вам нужно решить, что будет наиболее подходящим в зависимости от вашей программы. Если код взаимодействует с внешними службами (например, базой данных, веб-API, Интернетом), возможно, стоит показать архитектурную диаграмму.

В этом разделе вы также можете описать, как вы разработали свой метод . Это документ: это означает, что вы провели свое исследование. Поэтому может быть уместно показать здесь, как вы разработали процесс тестирования.

« Ключевые решения по реализации » — это то место, где вы должны показать, что вы испачкали руки, как фигуру речи. Здесь вам разрешено говорить о вашем коде или любом другом технологическом механизме, который вы использовали в своих исследованиях.

Имейте в виду, что вам не нужно комментировать все: только «ключевые» части, необходимые для понимания вашей программы. Никто не хочет читать статью, в которой вы описываете, как вы определили массив, поскольку это может сделать каждый. По сути, вы должны показать, как вы реализовали свой дизайн, что в нем интересного, что нового, что сложного и с какими трудностями вы столкнулись.

Вы можете захотеть показать «основную» часть вашей программы; вы можете обсудить, как вы решили улучшить общую производительность за счет использования различных структур данных во время разработки; вы можете обсудить, почему тот или иной метод дает наилучшие результаты, комментируя код. Это те «решения», которые принадлежат газете.