2.3 Руководство программиста

Руководство программиста (далее – РПрог) является техническим документом для разработчиков и технических специалистов. Документ содержит описание структуры программы, механизмов безопасности и особенностей реализации алгоритма КМП.

Документ содержит следующие разделы:

• Назначение и условия применения – описание среды выполнения, требования к ОС и оборудованию;

• Характеристика программы – описание архитектуры, ограничений входных данных: строка ≤ 10 000 символов, подстрока ≤ 1 000 символов, механизмов самотестирования;

• Обращение к программе – процедура запуска KMP.exe, порядок авторизации, описание ошибок запуска;

• Выполнение программы – описание основного функционала поиска, обработка некорректного ввода;

• Входные и выходные данные – таблицы входных и выходных сигналов с форматами и ограничениями;

• Сообщения оператору и программисту – описание сообщений об ошибках и структура журналов «/logs/kmp_log.txt».

2.4 Программа и методика испытаний

Программа и методика испытаний (далее ПМИ) – документ, предназначенный для проведения процедуры верификации разработанной программы на основании задания по безопасности. Документ разработан на основании ГОСТ Р 59795–2021.

Документ содержит разделы: объект испытаний, цель испытаний, требования к программе, требования к документации, средства и порядок испытаний, методы испытаний – 6 методов: проверка документации, проверка запуска, проверка корректного поиска, проверка отсутствия подстроки, проверка предельной длины строки, проверка некорректного ввода, перечень сокращений.

3 Проведение испытаний программного комплекса «кмп-поиск»

Проведению испытаний и оценки качества выполненной разработки подлежат следующие элементы документационного и программного обеспечения:

− техническое задание;

− задание по безопасности;

− руководство пользователя;

− руководство программиста;

− программа и методика испытаний;

− ПК «КМП-ПОИСК».

В данном разделе представлены результаты комплексной оценки комплекта проектных документов и программы «КМП‑ПОИСК». Анализ проводился на основании заранее утверждённых критериев и разработанной методики, что позволяет получить объективную картину готовности проекта к защите и дальнейшего практического применения.

Для каждого документа были рассчитаны баллы по отдельным показателям, сформулированы замечания и даны развёрнутые выводы о степени полноты и качества проработки материалов.

3.1 Оценка технического задания

Разработанное ТЗ оценивается на соответствие ГОСТ 34.602-2020 и ОС ТУСУР 01-2021 [6, 1].

Его оценка проводилась по 15 критериям, представленным на рисунке 3.1, охватывающим как формальное соответствие ГОСТ, так и содержательную полноту описания системы, требований и этапов разработки.

Рисунок 3.1 – Критерии оценки технического задания

В ходе анализа выяснилось, что структура документа в целом соответствует актуальной редакции ГОСТ 34.602‑2020, однако в тексте присутствуют опечатки, неравномерное форматирование и дублирование заголовков, что указывает на необходимость дополнительного нормоконтроля перед окончательной сдачей. Полноценные результаты оценки представлены в таблице 3.1.

Таблица 3.1 – Результаты оценки технического задания

Критерий	Описание критерия	Разбал-ловка	Макс. балл	Выст. балл	Комментарий к оценке
Актуальность документа	Оформление по ГОСТ	0–1	1	1	Структура соответствует ГОСТ 34.602‑2020, но присутствуют опечатки, дублирование заголовков и неравномерное форматирование. Требуется нормоконтроль.
Общие сведения	Наименование, заказчик, исполнитель, основания	0–2	2	2	Раздел 1 заполнен полностью и корректно.

Продолжение таблицы 3.1.

Критерий	Описание критерия	Разбал-ловка	Макс. балл	Выст. балл	Комментарий к оценке
Назначение системы	Корректное описание назначения	0–2	2	2	Раздел 2.1 отражает суть, но содержит грамматическую ошибку («введенным пользователем Алгоритм Кнута–Морриса–Пратта»); рекомендуется переформулировать.
Цели разработки	Указаны цели создания	0–2	2	2	Цели указаны, но носят тавтологичный характер; рекомендуется дополнить целями по точности, скорости и учебному назначению.
Характеристика объекта автоматизации	Описание объекта автоматизации	0–2	2	2	Объект автоматизации («функция поиска») описан полно и корректно для учебного проекта.
Функциональные требования	Перечень функций системы	0–2	2	1	В п. 4.1 присутствует «автоматизация регистрации», не полностью соответствующая фокусу на алгоритме КМП, есть опечатки; функции перечислены частично.
Структура системы	Подсистемы и их назначение	0–2	2	2	Раздел 4.2 логично выделяет подсистемы: поле ввода текста, подсистема регистрации в БД, ввод искомого слова, кнопки управления.
Требования к надёжности	Устойчивость и обработка ошибок	0–2	2	1	В п. 4.3 учтены только аппаратные сбои; отсутствуют требования к обработке исключений, некорректного ввода и пустых строк.
Контроль и приёмка	Порядок тестирования и приёмки	0–2	2	2	Раздел 6 описывает предварительные и приёмочные испытания, критерии проверки и порядок сдачи через ЭИОС и репозиторий GitHub.
Требования к документации	Перечень сопровождающей документации	0–2	2	2	Раздел 8 включает полный список документации (задание, ТЗ, ПЗ, электронные документы) и ссылки на стандарты.
ИТОГО			29	27

Раздел «Общие сведения» заполнен корректно и содержит все необходимые реквизиты. Назначение системы и характеристики объекта автоматизации описаны достаточно полно для учебного проекта, хотя в формулировках встречаются грамматические неточности, которые рекомендуется устранить. Цели разработки указаны, но носят несколько общий характер.

Функциональные требования отражены частично: в тексте упоминается «автоматизация регистрации», что несколько выходит за рамки основного фокуса проекта на алгоритме Кнута–Морриса–Пратта, при этом сами функции перечислены не в полном объёме. Требования к надёжности и безопасности проработаны на базовом уровне: учтены аппаратные сбои и физическая безопасность, однако отсутствуют чёткие положения об обработке исключений, механизмах хэширования паролей, таймаутах и логировании инцидентов, что является стандартным требованием для программных продуктов. При этом разделы, касающиеся условий эксплуатации, программной среды, этапов разработки, контроля и приёмки, а также перечня сопровождающей документации не вызывают нареканий.

По итогам анализа техническое задание набрало 27 баллов из 29 возможных. Выявленные замечания носят формально-логический характер и могут быть устранены в рамках доработки без изменения архитектуры или логики проекта.