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


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

===== Ответы на ключевые вопросы =====


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


===== Обзор аналогов =====

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


===== Собранная статья =====

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