Методические указания по подготовке и защите отчетов на специализации "Прикладная математика. Системное программирование". Кленин А.С. - 10 стр.

     Описать проблему, подлежащую решению — неизученный или недостаточно изу-
ченный вопрос, прояснение которого позволило бы достичь продвижения в той или иной
области науки или прикладного знания. Сделать вывод о необходимости или полезности
для решения данной проблемы проведения вычислительного эксперимента или другого
исследования с использованием программной системы.
     Работа относится к категории исследовательских, только если её результаты имеют
научную ценность сами по себе, а не являются утилитарной частью какого-либо научного
проекта. Например, база данных, хранящая результаты измерений, — прикладная задача, в
то время как алгоритм, строящий на основании этой базы данных какие-либо прогнозы и
выводы, может быть отнесён к научно-исследовательской работе.
     Рассмотреть пределы обобщения предполагаемых результатов.

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

     Раздел «1.3. Неформальная постановка задачи»
       Привести список пожеланий (неформальных требований) к системе, решающей про-
блему, поставленную в п. 1.1. Следует ограничиться общими утверждениями о наиболее
крупных возможностях, и не проводить их детализацию. Однако должны быть указаны все
свойства и особенности, необходимые для дальнейшего обсуждения в п. 1.3. При совмест-
ной разработке убедиться, что требования к системе согласованы и не совпадают с требо-
ваниями к другим подсистемам того же проекта.
       В случае если среди требований можно выделить нетривиальные отношения (напри-
мер, включения, расширения), и/или в системе имеется несколько акторов (ролей пользо-
вателей), привести диаграмму вариантов использования верхнего уровня.
       Пункты списка могут быть сформированы по правилам функциональных требований
(п. 5), реже — требований к данным (п. 4). Если количество пунктов превосходит 5–6, сле-
дует при помощи средств оформления визуально отделить эти виды требований. В целом
количество неформальных требований не должно быть более 10–15, а каждое требование
должно занимать 1–2 строки текста.
       Отдельно указать предполагаемую политику распространения программного продук-
та (только в организации-заказчике, продажа на открытом рынке, свободное распростра-
нение).


                                             10