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

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

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

Описание актуальности проблемы в заголовке самой проблемы. Описывать актуальность это хорошо и правильно, но их надо описывать отдельно (текст Проблемы не должен включать Актуальность).

Предмет исследования не связан с объектом исследования.

У вас более одного объекта или предмета.

Предмет сформулирован не как свойство (количественное или качественное) объекта.

Слишком широкий объект исследования.

Поставлено более одной цели/проблемы / объекта / предмета.

Проблема и/или цель имеют слишком узкую направленность/ уже чем фактическая цель работы - например «получить значение производительности библиотеки libxml» вместо «найти наиболее производительную библиотеку/ выработать метод оценки производительности».

Проблема формулируется как отсутствие / недостаток / недостаточность чего-то, например «отсутствие удобного/производительного/безопасного сервиса заказа такси». Более гладкий вариант: «Организация удобного/производительного/безопасного сервиса заказа такси».

Задачи не раскрывают цель полностью.

Проблема и цель явно не связаны.

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

Список задач не выполним за текущий семестр (задачи для статьи, а не для ВКР)

В тексте используются синонимы для обозначения вашего результата. Надо использовать один термин.

Список задач содержит задачи субъективные (Изучить …, прочитать …, разобраться …., установить и настроить ….). Они не связаны с вашим исследованием (они больше про вас как про разработчика), кроме того, считается, что они для вас являются чем-то само собой разумееющимся (и таким мелочам в статье не надо уделать внимание).

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

В принципе отбора отсутствуют указание на класс систем / решений, по которым проводился поиск.

Описания аналогов скопированы с сайтов самих аналогов.

Описания аналогов не характеризуют их с точки зрения цели.

Критерии сравнения далеки от поставленной цели (обзор не приближает к достижению цели).

Субъективные критерии - зависят от конкретного человека.

Критерии неосязаемые / нет информации о том, как , кто, на каком компьютере, на каких данных измерил.

Субъективные оценки по критериям - хорошо, плохо, много, мало, быстро, медленно, средне и тд. ИЛИ замените на количественные значения и предоставьте информацию о том, кто, на каких данных, в каких условиях и как их измерил, ИЛИ (если критерий качественный) укажите как аналог характеризуется (например, критерийм- наличие механизма авторизайии, значение - указать протоколы, способы, ограничения … ).

Не нужно для качественных критериев придумывать количественные шкалы.

«нет аналогов» / Мало аналогов (а как же тривиальные / эмпирические решения или отсутствие решения?).

Отсустствуют обоснования для критериев, особенно если 1) критериев много 2) критерии не очевидны

Отсутствует описание методики измерения критерия.

Сами аналоги не связаны с целью.

Вывод по итогам обзора не показывает направлений для новых решений проблемы (аналоги решают проблему нужным образом).

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

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

Бинарных значений критериев недостаточно, нужна конкретика - как какой аналог выполняет или не выполняет определенный критерий.

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

Аналоги выбраны приемущественно из русскоязычных ресурсов. Для задач, которые не привязаны к специфике страны / региона / законодательству / местным стандартам, очень важно изучить мировой опыт - часто, поиск среди англоязычных решений позволяет найти решения с открытым исходным кодом и/или множество патентов / статей по проблеме.

Выбор метода решения:

Требования не конкретны / не верифицируемы (интуитивный / удобный интерфейс).

Требования не следуют из проведенного обзора

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

Смысл выводов по итогам сравнения не в том, чтобы текстом повторить содержимое таблицы, а в том, чтобы оценить пригодность аналогов и/или их общие свойства в контексте вашей задачи и ее специфики.

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

Ключевое слово …… слишком общее. Его нужно или уточнить, или убрать из списка.

Аннотация слишком краткая. Аннотация - это самый читаемый раздел статьи, поэтому ее задача - увлечь читателя путем демонстрации технических подробностей и основных результатов, поэтому, добавьте больше конкретных деталей по промежуточным и финальным результатам.

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

Ссылки на литературу указывают в тексте раздела, а не в заголовках разделов и подразделов.

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

Размер и количество картинок (особенно скриншотов) могут произвести впечатление попытки повысить объем. Давайте ограничим их количество 4 штуками и сократим занимаемый объем также в четыре раза.

Таблицы / изображения не имеют подписей / ссылок в тексте.

Не все элементы списка литературы упомянуты в тексте. Либо удалите не упомянутые, либо добавьте ссылки в тексте.

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

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

При первом упоминании каждой технологии / метода / фреймворка / инструмента необходимо давать ссылку на источник с описанием.

В выводах нет конкретики по задачам. Раздел «Выводы» третий по читаемости в статье (Сначала читают аннотацию, затем введение, потом выводы и только после - остальной текст). Нужно указать, какой именно результат был получен в каждой задаче и как это помогает / мешает достижению цели.

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