Типовые ошибки в заданиях

Ниже описываются типовые замечания для заданий данного курса.

1. Актуальность:
   1. Слишком сильные утверждения без опоры на источник.
   2. В Актуальности нет ссылок на источники, подтверждающие приведенные утверждения. Без ссылок это выглядит как мнение автора, а не факты.
   3. Описание актуальности в тексте проблемы. Описывать актуальность нужно отдельно (текст Проблемы не должен включать Актуальность).
2. Проблема:
   1. Проблема не должна формулироваться как отсутствие / недостаток / недостаточность чего-то, например «отсутствие удобного/производительного/безопасного сервиса заказа такси». Более гладкий вариант: «Организация удобного/производительного/безопасного сервиса заказа такси».
   2. Проблема должна быть шире Цели (Проблема ~ мегацель в принципе нерешаемая, а Цель - конкретная и достижимая).
   3. Проблема и цель явно не связаны.
3. Объект и предмет исследования:
   1. Слишком широкий объект исследования.
   2. Предмет сформулирован не как свойство (количественное или качественное) объекта.
   3. Предмет исследования не связан с объектом исследования.
4. В цели должно быть явно сказано, что за результат вы хотите получить (например, разработать драйвер клавиатуры или провести обзор моделей распознавания иероглифов), и КАКИМ этот результат должен быть (например, «… драйвер для клавиатуры, использующий технологии … и …, обеспечивающий работу в режиме …» или «… моделей распознавания иероглифов для решения задачи перевода с китайского на шведский, запуская модель на встраиваемой платформе такой-то»).
5. Задачи:
   1. Количество задач не укладывается в диапазон 3-5. Меньше трех это слишком мало (исследование кажется несостоятельным), а если задач больше пяти, то вы сами себе роете яму (показать достижение более пяти задач достаточно тяжело в объеме курса).
   2. Список задач не выполним за текущий семестр (задачи для статьи, а не для ВКР)
   3. Задачи не раскрывают цель полностью.
   4. Список задач содержит задачи субъективные (Изучить …, прочитать …, разобраться …., установить и настроить ….). Они не связаны с вашим исследованием (они больше про вас как про разработчика), кроме того, считается, что они для вас являются чем-то само собой разумееющимся (и таким мелочам в статье не надо уделать внимание).
6. Общий стиль и взаимосвязь ответов на ключевые вопросы:
   1. Поставлено более одной цели / проблемы / объекта / предмета.
   2. Проблема и/или цель имеют слишком узкую направленность/ уже чем фактическая цель работы - например «получить значение производительности библиотеки libxml» вместо «найти наиболее производительную библиотеку / выработать метод оценки производительности».
   3. В рамках проблемы / цели / задачи … не дается конкретизации по специфики задачи, используются общие термины (данные, изображения …). Было бы хорошо изложить чуть подробнее в формулировке конкретику - какие именно задачи и для кого планируется решать (детали сценария использования), подробности по используемым данным (форматы, специфика).
   4. В тексте используются разные слова для обозначения вашего результата. Надо использовать один термин.

1. Принцип отбора аналогов:
   1. В принципе отбора отсутствуют указание на класс систем / решений, по которым проводился поиск.
   2. В принципе отбора отсутствует перечнь запросов для поиска.
2. Характеристика аналогов:
   1. В тексе описания аналогов нет ссылки на источник.
   2. Описания аналогов скопированы с сайтов самих аналогов.
   3. Описания аналогов не характеризуют их с точки зрения цели.
   4. Сами аналоги не связаны с целью.
   5. Аналоги выбраны приемущественно из русскоязычных ресурсов. Для задач, которые не привязаны к специфике страны / региона / законодательству / местным стандартам, очень важно изучить мировой опыт - часто, поиск среди англоязычных решений позволяет найти решения с открытым исходным кодом и/или множество патентов / статей по проблеме.
   6. Аналоги выбраны из очень узкой области, игнорируются альтернативные способы (с помощью других моделей, подходов, алгоритмов) для решения проблемы.
3. Критерии сравнения:
   1. Критерии сравнения далеки от поставленной цели (обзор не приближает к достижению цели).
   2. Субъективные критерии - зависят от конкретного человека.
   3. Критерии неосязаемые / нет информации о том, как , кто, на каком компьютере, на каких данных измерил.
   4. Субъективные оценки по критериям - хорошо, плохо, много, мало, быстро, медленно, средне и тд. ИЛИ замените на количественные значения и предоставьте информацию о том, кто, на каких данных, в каких условиях и как их измерил, ИЛИ (если критерий качественный) укажите как аналог характеризуется (например, критерийм- наличие механизма авторизайии, значение - указать протоколы, способы, ограничения … ).
   5. Не нужно для качественных критериев придумывать количественные шкалы.
   6. «нет аналогов» / Мало аналогов (а как же тривиальные / эмпирические решения или отсутствие решения?).
   7. Отсустствуют обоснования для критериев, особенно если 1) критериев много 2) критерии не очевидны
   8. Отсутствует описание методики измерения критерия.
   9. Критерий не выполняется ни одним из аналогов. В текущем виде это сужает картину обзора - у читателя могут быть вопросы или к выбору аналогов (зачем вы выбрали одинаковые аналоги), или к качеству формулировки критерия (читатель может подумать, что вы специально выбрали такие критерии, по которым настолько одинаковая картинка). Нужно или уточнить значения для критерия (указать подробнее, как именно аналоги не удовлетворяют / в чем удовлетворяют), или дополнить обзор еще одним критерием: менее однозначным, но все равно связанным с вашей задачей и целью.
   10. Бинарных значений критериев недостаточно, нужна конкретика - как какой аналог выполняет или не выполняет определенный критерий.
   11. Часть критериев не относятся к технической стороне вопроса - а именно не связаны с тем техническим решением, которое вы будете создавать. Поскольку у вас техническая специальность, то вопросы локализации, стоимости, наличие форумов поддержки и открытости кода не связаны с вашим решением напрямую. Гораздо важнее рассмотреть технологии, протоколы, способы выполнения тех или иных сценариев использования.
4. Выводы:
   1. Вывод по итогам обзора не показывает направлений для новых решений проблемы (аналоги решают проблему нужным образом).
   2. Выводы по итогам обзора (в аннотации, тексте и тд) слишком общий и явно негативный («По результатам обзора установлено, что ни один из существующих методов не удовлетворяет всем необходимым требованиям»). Это не помогает статье, так как с таким выводом возникают вопросы 1) почему вы не расширили поиск, если текущий набор аналогов так плох? 2) может быть, дело в критериях?. Предлагаю вывод сделать более подробным и конкретно указать на общие недостатки и достоиннства решений.
   3. Смысл выводов по итогам сравнения не в том, чтобы текстом повторить содержимое таблицы, а в том, чтобы оценить пригодность аналогов и/или их общие свойства в контексте вашей задачи и ее специфики.
5. Выбор метода решения:
   1. Не сказано конкретно, чем будет планируемое решение (программа, приложение, драйвер, нейронная сеть, алгоритм, математическая модель ….).
   2. Планируемое решение не соответствует специальности. У нас (ПМИ и ПИ), как правило результаты это или что-то программное, или программно-аппаратное (с упором на программную часть), или математическое (модели / алгоритмы / … эти результаты всегда дополняются программной реализацией и экспериментами), или ИИшное (нейронные сети, LLM, генетические алгоритмы и подобное).
   3. Планируемое решение не соответствует уровню проработки ВКР и больше напоминает по постановке задачу из лабораторной / курсовой. ВКР по определению И / ИЛИ создание чего-то нового (нужного, полезного, сложного), И / ИЛИ значительная доработка чего-то существующего (объемная / сложная), И/ИЛИ достижение каких-то измеримых количественных / качественных результатов (например, увеличили точность работы модели на Н процентов с помощью … / ускорили программу в Х раз за счет …).
   4. Выдвигаемые требования не конкретны и/или субъективны (интуитивный / удобный интерфейс).
   5. Выдвигаемые требования не следуют из проведенного обзора.
   6. Выдвигаемые требования к решению не верифицируемы (== их нельзя проверить в экспериментах и это очевидно еще на этапе подготовки данного задания).
6. Весь обзор выполнен в общем, в вакууме, в поиске общих плюсов и минусов. Характеристики аналогов, критерии сравнения и значения по ним не дают ответа на вопрос «Насколько хорошо эти аналоги подходят для решения вашей конкретной проблемы в ее специфике?»

1. Аннотация слишком краткая. Аннотация - это самый читаемый раздел статьи, поэтому ее задача - увлечь читателя путем демонстрации технических подробностей и основных результатов, поэтому, добавьте больше конкретных деталей по промежуточным и финальным результатам.
2. Ключевое слово …… слишком общее. Его нужно или уточнить, или убрать из списка.
3. Выводы по итогам обзора (в аннотации, тексте и тд) слишком общий и явно негативный («По результатам обзора установлено, что ни один из существующих методов не удовлетворяет всем необходимым требованиям»). Это не помогает статье, так как с таким выводом возникают вопросы 1) почему вы не расширили поиск, если текущий набор аналогов так плох? 2) может быть, дело в критериях?. Предлагаю вывод сделать более подробным и конкретно указать на общие недостатки и достоиннства решений.
4. Очень много разделов, состоящих из двух или менее предложений. Такие разделы необходимо либо объединить между собой, либо добавить в них больше текста - редакторы очень неприятно реагируют на них.
5. Размер и количество картинок (особенно скриншотов) могут произвести впечатление попытки повысить объем. Давайте ограничим их количество 4 штуками и сократим занимаемый объем также в четыре раза.
6. Таблицы / изображения не имеют подписей / ссылок в тексте.
7. При первом упоминании каждой технологии / метода / фреймворка / инструмента необходимо давать ссылку на источник с описанием.
8. Ссылки на литературу указывают в тексте раздела, а не в заголовках разделов и подразделов.
9. Не все элементы списка литературы упомянуты в тексте. Либо удалите не упомянутые, либо добавьте ссылки в тексте.
10. В вашей работе очень много текста в скобках. Либо удалите его, либо замените скобки на запятые. В текущем варианте он демонстрирует редактору неуверенность в описанных результатах.
11. Местами текст вашей статьи страдает от «телеграфности» - предложения кажутся отрывистыми, не связанными друг с другом и манерой изложения напоминают сводки боевых действий (Враг занял левый берег Волги. Моральный дух личного состава высокий. В атаку идем по расписанию.).
12. В выводах нет конкретики по задачам. Раздел «Выводы» третий по читаемости в статье (Сначала читают аннотацию, затем введение, потом выводы и только после - остальной текст). Нужно указать, какой именно результат был получен в каждой задаче и как это помогает / мешает достижению цели.
13. В вашей работе нет содержательной конкретики - вы ищите «сильные и слабые стороны», «плюсы и минусы», тогда как вам нужно рассказывать о том, как решается ваша задача.