Как спроектировать и структурировать техническую/программную диссертацию

Я сейчас пишу диплом бакалавра. Объем этой диссертации составит примерно 25-30 тысяч слов/80-100 страниц контента.

До сих пор мы писали обзоры литературы только во время учебы. Мой тезис, однако, будет более техническим: тезис будет о приложении, которое я разрабатываю.

Поскольку раньше я в основном делал обзоры литературы, у меня есть некоторые сомнения относительно того, как я структурировал/обосновал диссертацию. Хотя у меня есть (я думаю) общее представление о том, как это сделать, благодаря онлайн-исследованиям и разговорам с моим консультантом, я не совсем уверен, что понял «общую картину» написания диссертации, посвященной развитию. приложения.

Большая часть проанализированного мной материала, касающегося разработки приложений, относительно короткая (менее 10 страниц), поэтому его структуру трудно применить в моей диссертации. У меня такое ощущение, что при необходимости я мог бы сократить диссертацию примерно до 15 страниц. Однако, если бы я хотел объяснить все, что я делал в ходе разработки, мне, вероятно, понадобилось бы более 200 страниц.

Мой первый вопрос: как я могу найти хорошую золотую середину между этими крайностями?

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

Следовательно, второй вопрос: как должен быть сформулирован хороший «вклад в науку» для такого рода диссертации? Какие моменты он должен решить?

Вы должны проверить предыдущие дипломы бакалавра в вашем отделе рядом с вашим и спросить своего консультанта, так как он (и комитет) оценивает их.
@Alexandros На моем факультете не так много бакалаврских диссертаций этого типа. Мой советник уже дал мне несколько хороших советов, как я уже упоминал в своем посте. Смысл моего вопроса в том, чтобы получить более общий взгляд на эту проблему, поскольку я чувствую, что эта тема гораздо шире, чем я знаю в настоящее время.

Ответы (1)

Вы почти наверняка должны сместить фокус — совсем немного. Не отчаивайтесь, это скорее возможность увидеть все под другим углом.

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

Проверенный временем подход состоит в том, чтобы представить гипотезу. Может быть, речь идет о том, как какую-то проблему вообще можно решить/быстрее, чем это было известно раньше/намного элегантнее. Чтобы добиться честного и достоверного представления, вам придется немного написать о подходе ваших предшественников в этой области.

Теперь введите свое программное обеспечение. Для письменной диссертации это просто инструмент для проверки вашей гипотезы. Написание некоторых важных дизайнерских решений должно быть уместным, если они тесно связаны с возможностью проверки вашей гипотезы.

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

Таким образом, вы создадите диссертацию на более общую тему (используя свое программное обеспечение в качестве исследовательского инструмента), а также внесете свой вклад в науку. Другие могут проверить ваши результаты, попробовать и сравнить свои собственные подходы и так далее. Вот почему ваш тезис должен быть о проблеме , предлагаемом вами решении и его свойствах, а не об инструментах, которые вы создали в ходе этого процесса.