Как правильно писать выпускную квалификационную работу программисту

Программирование Как правильно писать выпускную квалификационную работу программисту

Помечено: 

В этой теме 0 ответов, 1 участник, последнее обновление  Васильев Владимир Сергеевич 4 дн., 5 час. назад.

  • Автор
    Сообщения
  • #5350
    @admin

    Программисты разрабатывают документацию, а студенты – пишут пояснительную записку к выпускной квалификационной работе (ВКР). Это две разные вещи, однако если писать ВКР «правильно», то результат будет похожим. В статье описано как писать ВКР так, чтобы не пришлось «лить воду» и «высасывать из пальца». Касаются эти «советы» только работ, связанных с разработкой программ или (отчасти) систем управления.

    Содержание:

    1. Выбор темы.
    2. Структура.
      1. Анализ
      2. Проектирование
      3. Реализация
    3. Про что тут не сказано?

    1 Выбор_темы

    При выборе темы нужно учитывать следующее:

    • В ВКР студент должен показать чему он научился в ВУЗе. Тема работы должна позволять студенту продемонстрировать свои навыки.
    • У работы должна быть практическая или научная ценность. Она должна быть хоть чем-то полезной.
    • В итоге должна получиться законченная работа (какой-то продукт).

    Типичные ошибки:

    • «разработка сайта интернет магазина» — плохая тема. Потому что «берем готовую CMS и …». Не получится показать чему мы учились в ВУЗе так долго.
    • «разработка CMS» / «разработка игрового движка» — плохие темы. Не получится довести их до такого состояния, чтобы получился полезный продукт.

    2 Структура

    Разработку проекта я рекомендую вести по методологии ICONIX по следующим причинам:

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

    В тексте ВКР стоит отразить процесс разработки, а не конечный вариант. Комиссии интересно узнать как вы пришли к конечному решению, проводили анализ вариантов решения и т.д. Описание работы осложняется тем, что процесс ICONIX, как и RUP, является итеративным (вы многократно перерабатываете одну и ту же диаграмму), а текст пояснительной записки – линейным.
    В структуре работы стоит выделить 3 главы.

    2.а Анализ

    В первой главе необходимо:

    • Сформировать техническое задание (ТЗ). Оно описывается значительно более подробно, чем задание на дипломное проектирование, выдаваемое руководителем. Я рекомендую задавать его в виде модели предметной области, прецедентов и макетов интерфейса. Прецеденты – это почти то же самое, что пользовательские истории (user stories), применяемые с той же целью в экстремальном программировании (XP) и Scrum. В ряде случаев ТЗ описывают на основе ГОСТ 34.602-89 для аппаратной части и ГОСТ 19.201-78 – для программной. В таком случае use-case диаграммы можно вынести во второй раздел.
    • Провести анализ проектов, которые могли бы помочь в разработке (чаще всего с отрытой лицензией (MIT, GPL, …)).

    Типичные ошибки:

    • Отсутствие четко поставленного ТЗ, пока его нет – разрабатывать нечего.
    • Анализ языков программирования, фреймворков и т.п., не связанного с техническим заданием. Чаще всего такой анализ подгоняется под тот набор технологий, который студент знает лучше всего. Не получится нормально обосновать чем Java лучше чем Erlang или C++.
    • Обзор аналогов. Часто выполняют обзор готовых проектов, которые никак не могут помочь в разработке. Иногда при этом делается попытка обосновать необходимость новой разработки (ни один из аналогов не удовлетворяет требованиям). Делать это не нужно – студенту дали задание, он должен грамотно его выполнить, а не рассуждать о том нужно это или нет.

    Яркий пример: Студент получил задание на разработку системы управления базой данных военкомата, в которой несколько работников должны иметь возможность одновременной работы с одной базой, находящейся на сервере. Провел анализ аналогов (в том числе 1С), в каждом нашел недостатки. Провел анализ языков программирования и баз данных, выбрал C# и MySQL. В итоге плохо реализовал работу. Лучше было разрабатывать решение на базе 1С, притом, что 1С предоставляет специальное защищенное решение для силовых ведомств.

    2.б Проектирование

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

    2.c Реализация

    В разделе реализации нужно описать:

    • Используемые при разработке инструменты – язык программирования, БД, библиотеки, системы тестирования и т.п..
    • Примененные для решения проблем (указанных в разделе 2) шаблоны проектирования.
    • Инструкции по сборке проекта из исходного кода, его настройке и запуску.
    • Организацию тестирования – какие части системы покрыты модульными тестами и т.д.

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

    3 Про что тут не сказано?

    Тут ничего не сказано про то:

    1. Как эту работу привести в соответствие со стандартами (ГОСТ/СТО).
    2. Как подготовить презентацию и выступление.

Для ответа в этой теме необходимо авторизоваться.