Основная цель преддипломной практики состоит в сборе фактического материала для выполнения выпускной квалификационной работы бакалавра. Прохождение преддипломной практики на кафедре информационных систем ЧОУ ВО «Московский университет им. С.Ю. Витте» позволяет получить ценный практический опыт по проектированию корпоративных информационных систем с точки зрения автоматизации отдельных бизнес-процессов структурного подразделения, выявления недостатков и последующих предложений по их устранению.
В контексте цифровой трансформации образовательной деятельности особую актуальность приобретает автоматизация документооборота, в частности процессов создания и согласования проектной документации. В рамках подготовки выпускных квалификационных работ, научно-исследовательских проектов и закупок программного обеспечения в университете регулярно возникает необходимость формирования технических заданий (ТЗ). В настоящее время данный процесс в университете характеризуется высокой долей ручного труда, использованием разрозненных шаблонов текстовых редакторов, сложностями контроля версий и согласований, что приводит к снижению производительности и риску несоблюдения установленных стандартов.
Модернизация данного процесса заключается в разработке и внедрении специализированного веб-сервиса, который обеспечит сквозную автоматизацию создания, редактирования, согласования и утверждения ТЗ в строгом соответствии с требованиями ГОСТ 34.602-2020. Решение данной задачи состоит в проведении детального анализа существующего бизнес-процесса, формализации требований всех категорий пользователей, проектировании оптимальной архитектуры системы и реализации работоспособного прототипа.
Разрабатываемый веб-сервис, условно именуемый «ТехЗадание-Конструктор», будет представлять собой интуитивно понятный онлайн-инструмент с интерфейсом, построенным по принципу конструктора. Система позволит пользователям на основе типовых шаблонов, структурированных по разделам ГОСТ, быстро формировать проектные документы, проходить многоэтапное согласование в цифровом виде и экспортировать итоговые документы в стандартные форматы. Внедрение такого решения позволит унифицировать процесс, минимизировать ошибки, повысить прозрачность и скорость подготовки проектной документации в университете.
Цель практики – получение практического опыта анализа, проектирования и разработки веб-ориентированных информационных систем для автоматизации бизнес-процессов в образовательном учреждении на примере создания системы автоматизированного формирования технического задания в ЧОУ ВО «Московский университет им. С.Ю. Витте».
Задачи практики:
изучить организационную структуру, нормативную документацию и ИТ-инфраструктуру кафедры информационных систем университета;
провести анализ и формализацию текущего бизнес-процесса формирования технического задания (модель AS-IS) и определить требования ключевых пользователей;
разработать техническое задание на создание веб-сервиса автоматизации в соответствии со стандартом ГОСТ 34.602-2020;
спроектировать оптимизированную модель бизнес-процесса (TO-BE), архитектуру веб-сервиса и структуру базы данных;
реализовать функциональный прототип веб-сервиса «ТехЗадание-Конструктор», включая модуль конструктора документов, систему согласования и экспорта в формате .docx;
обеспечить разграничение прав доступа для различных ролей пользователей (студент, руководитель, администратор);
оформить результаты работы в виде отчета по преддипломной практике, формируя основу для выпускной квалификационной работы.
Источниками информации для проведения аналитической работы явились организационно-правовые документы ЧОУ ВО «Московский университет им. С.Ю. Витте», размещенные в открытом доступе на официальном сайте университета, внутренние регламенты кафедры информационных систем, стандарт ГОСТ 34.602-2020, а также интервью и опросы потенциальных пользователей системы.
АНАЛИТИЧЕСКОЕ ОБСЛЕДОВАНИЕ ПРОЦЕССА ФОРМИРОВАНИЯ ТЕХНИЧЕСКОГО ЗАДАНИЯ В ЧОУ ВО «МОСКОВСКИЙ УНИВЕРСИТЕТ ИМ. С.Ю. ВИТТЕ»
Исходные данные для отчета
Тема выпускной квалификационной работы (ВКР): «Разработка системы для автоматизированного формирования технического задания в соответствии с ГОСТ (на примере Частного образовательного учреждения высшего образования «Московский университет имени С.Ю. Витте»)».
Бизнес-процесс, рассматриваемый в рамках практики: «Процесс подготовки, согласования и утверждения технического задания на разработку программного обеспечения в рамках выпускных квалификационных работ студентов направления «Бизнес-информатика»».
Обоснование выбора процесса: данный процесс является критически важным для инициации и формализации выпускных квалификационных работ студентов IT-направлений и научно-исследовательских проектов, выполняемых на кафедре информационных систем. Он характеризуется высокой степенью регламентации (ГОСТ 34.602-2020), вовлеченностью нескольких ролей (студент-автор, научный руководитель, заведующий кафедрой) и в текущем состоянии подвержен рискам, связанным с ручным трудом, разрозненностью данных и длительными циклами согласования.
Подразделение, отвечающее за реализацию и совершенствование данного процесса: кафедра информационных систем факультета информационных технологий ЧОУ ВО «МУ им. С.Ю. Витте».
Ссылка на Git-репозиторий проекта:
https://gitflic.ru/project/borovskiy/auto_tech_spec
Ссылка на хостинг с размещенным веб-ресурсом: http://borovs9r.beget.tech/
Учетные данные для тестирования системы:
администратор: логин admin@muiv.ru, пароль admin2025;
руководитель (преподаватель): логин teacher@muiv.ru, пароль teacher1;
студент/исполнитель: логин student@muiv.ru, пароль student1.
Анализ организационной структуры и нормативной базы ЧОУ ВО «МУ им. С.Ю. Витте»
Анализ организационной структуры университета и его нормативной базы является фундаментальным этапом для корректной идентификации всех участников бизнес-процесса, их ролей и установленных регламентов. Московский университет имени С.Ю. Витте, основанный в 1993 году, является одним из первых и крупнейших негосударственных вузов России, реализующим образовательные программы от колледжа до аспирантуры по ключевым направлениям, таким как экономика, менеджмент, юриспруденция и информационные технологии. Организационная модель университета построена по классическому линейно-функциональному принципу с четким разделением на органы управления, административно-управленческие, академические подразделения и филиальную сеть.
Высшим единоличным исполнительным органом университета является ректор (Семенов Александр Вячеславович), который осуществляет общее руководство деятельностью вуза. В непосредственном подчинении ректора находятся коллегиальные органы: ректорат, координирующий оперативную деятельность, и Ученый совет, определяющий стратегию научно-образовательного развития.
Все остальные структурные единицы университета можно разделить на три крупных кластера:
административно-управленческие подразделения, обеспечивающие жизнедеятельность вуза (бухгалтерия, канцелярия, службы персонала и маркетинга, учебные и методические отделы);
академические подразделения, включающие факультеты и кафедры, которые реализуют основные образовательные программы. В их числе – Факультет информационных технологий с профильной для темы ВКР Кафедрой информационных систем;
филиалы, территориально удаленные от головного офиса, но работающие в едином правовом и методическом поле (например, в Сергиевом Посаде, Нижнем Новгороде, Рязани).
Наглядное представление ключевых взаимосвязей в структуре университета, с фокусом на кафедру информационных систем и взаимодействие с Департаментом информационных технологий (ДИТ), отражено на следующей диаграмме (рисунок 1).
Рисунок 1 – Организационная структура МУИВ с фокусом на ДИТ
Как видно из диаграммы и подтверждается внутренним «Положением о департаменте информационных технологий», ДИТ занимает центральное место в контексте технической поддержки процессов автоматизации университета. Руководитель ДИТ является проректором по ИТ и подчиняется напрямую ректору, что подчеркивает стратегическую важность подразделения. Однако в рамках рассматриваемого бизнес-процесса подготовки технических заданий для выпускных квалификационных работ владельцем процесса и заказчиком системы выступает кафедра информационных систем, так как именно она отвечает за содержательную сторону образовательной деятельности.
Согласно «Положению о кафедре информационных систем», в компетенцию кафедры входят задачи и функции, напрямую охватывающие анализируемый процесс:
организация и руководство выпускными квалификационными работами студентов;
назначение научных руководителей и определение тематики ВКР;
контроль соответствия оформления выпускных квалификационных работ установленным стандартам (включая технические задания);
методическое обеспечение образовательного процесса.
Департамент информационных технологий, в свою очередь, согласно своему положению, выполняет функции технического партнера:
обеспечение серверной инфраструктуры для развертывания информационных систем (п. 28);
поддержка функционирования корпоративного портала и электронной информационно-образовательной среды (п. 42, 45);
обеспечение безопасности и конфиденциальности данных (п. 14, 30);
консультирование пользователей по порядку работы с системами (п. 21).
Взаимодействие кафедры информационных систем с ДИТ в контексте автоматизации:
В рамках проекта по автоматизации формирования ТЗ роли подразделений распределены следующим образом:
Кафедра информационных систем выступает в роли заказчика и владельца процесса. Сотрудники кафедры формулируют требования к системе, определяют бизнес-процесс согласования (студент → научный руководитель → заведующий кафедрой), участвуют в приемочных испытаниях.
Департамент информационных технологий выступает в роли технического партнера, обеспечивающего:
выделение серверных ресурсов для размещения веб-сервиса;
поддержку сетевой инфраструктуры и обеспечение информационной безопасности;
консультационную поддержку при интеграции с существующими сервисами университета (при необходимости).
Такое разделение ответственности соответствует сложившейся в университете практике, где содержательное наполнение образовательного процесса находится в ведении академических подразделений, а техническое сопровождение – в ведении ДИТ.
Порядок реализации бизнес-процесса и регулирующая нормативная документация.
Текущий процесс подготовки и согласования технических заданий для ВКР носит кросс-функциональный характер и затрагивает несколько категорий участников в рамках кафедры:
инициатор и автор – студент выпускного курса;
эксперт и рецензент – научный руководитель (преподаватель кафедры);
утверждающее лицо – заведующий кафедрой информационных систем.
Процесс следует по схеме:
студент получает тему ВКР и задание от научного руководителя;
студент готовит черновик технического задания;
научный руководитель проверяет документ, вносит замечания;
студент дорабатывает ТЗ с учетом замечаний;
после утверждения научным руководителем документ передается заведующему кафедрой;
заведующий кафедрой утверждает техническое задание.
Основным внешним нормативным документом, жестко регулирующим содержание и оформление ТЗ, является ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Внутреннее регулирование процесса осуществляется через Устав университета, Положение о кафедре информационных систем, Положение о выпускной квалификационной работе, а также внутренние регламенты документооборота, утверждаемые ректоратом.
Анализ и формализация бизнес-процесса формирования ТЗ (модель
AS-IS)
Выбор для автоматизации бизнес-процесса «Подготовка, согласование и утверждение технического задания» обусловлен его высокой стратегической значимостью для проектной деятельности кафедры информационных систем. Однако для объективного обоснования необходимости автоматизации недостаточно констатации качественных проблем – требуется их количественная оценка. В связи с отсутствием централизованного учета показателей данного процесса в информационных системах университета, для сбора исходных данных был применен метод структурированного интервью и ретроспективного анализа.
Источники информации и методология сбора данных:
Целевая группа опроса – 12 студентов выпускных курсов направления «Бизнес-информатика» и «Прикладная информатика» Факультета информационных технологий, завершивших подготовку ВКР в 2024-2025 учебном году (метод «доступной выборки»).
Метод сбора – полуформализованное интервью, в ходе которого респондентам предлагалось восстановить хронологию работы над ТЗ к своей ВКР и оценить ряд количественных параметров, а также предоставить архив переписки с научным руководителем (при наличии).
Обрабатываемые данные – анализ электронных писем (темы: «ТЗ», «Техническое задание», «Замечания по ТЗ») и файловых архивов, предоставленных респондентами на добровольной основе.
Проведенный анализ позволил получить следующие усредненные данные, характеризующие текущее состояние процесса:
От момента отправки первой версии черновика научному руководителю до получения финального утвержденного варианта в среднем проходило 12,4 календарных дней. Минимальное зафиксированное значение – 3 дня (при высокой оперативности сторон), максимальное – 31 день (в период сессии или отпуска руководителя). Данный показатель не учитывает время, затраченное автором на первоначальную подготовку документа по шаблону.
В среднем документ проходил 3,8 итерации правок до момента утверждения. При этом в 67% случаев респонденты сообщали о потере контекста правок («не помню, почему это исправил», «замечание было в письме, а не в файле»). В 42% случаев возникали ситуации, когда руководитель правил не ту версию файла, которую прислал студент.
По оценкам респондентов, от 40% до 55% общего времени, затраченного на работу с ТЗ, уходило не на содержательную часть (описание требований к системе), а на техническое оформление: поиск актуального шаблона, форматирование текста в соответствии с ГОСТ, ручное исправление нумерации разделов после вставки правок. Средняя оценка по группе – 48%.
При проверке финальных версий ТЗ, предоставленных респондентами (n=8), было выявлено, что только 2 из 8 (25%) полностью соответствовали требованиям ГОСТ 34.602-2020 по структуре и наличию обязательных разделов. В остальных случаях наблюдались пропуски разделов, нарушение иерархии или использование устаревшей редакции стандарта.
100% респондентов хранили итоговый файл ТЗ на локальном компьютере. Только 3 из 12 (25%) могли оперативно предоставить архив всех промежуточных версий и переписки по согласованию. В остальных случаях переписка была частично утеряна или хранилась в неструктурированном виде.
Полученные количественные оценки позволяют сформулировать измеримые цели для проектируемой автоматизированной системы:
Цель 1 (по времени). Сокращение среднего цикла согласования с 12,4 до не более 5 календарных дней (целевое сокращение ~60%). Это достигается за счет исключения задержек, связанных с ручной пересылкой файлов и поиском актуальных версий.
Цель 2 (по итерациям). Снижение среднего количества итераций с 3,8 до не более 2 (целевое сокращение ~47%) за счет привязки комментариев к конкретным разделам и единой среды редактирования, исключающей разночтения.
Цель 3 (по качеству оформления). Обеспечение 100% соответствия структуры итогового документа требованиям ГОСТ 34.602-2020 за счет использования валидируемых встроенных шаблонов и автоматической генерации финального документа.
Цель 4 (по сохранности). Обеспечение полного цифрового архива всех версий и комментариев по каждому проекту с возможностью поиска и восстановления.
Представленные количественные данные, полученные путем опроса реальных участников процесса (студентов и их научных руководителей) и анализа документооборота, объективно подтверждают наличие системных проблем. Текущий процесс характеризуется высокой длительностью (более 12 дней), избыточным количеством итераций (почти 4), значительными непроизводительными трудозатратами (около 50%) и низким качеством итоговой документации (только 25% соответствуют ГОСТ). Данные метрики являются базой для последующей оценки эффективности внедрения разрабатываемого веб-сервиса.
Формализация модели AS-IS в нотации IDEF0:
Для формализации и детального анализа существующей логики процесса использована методология функционального моделирования IDEF0. Данная нотация позволяет четко определить границы процесса, его входы, выходы, управляющие воздействия и исполнителей, что является основой для последующего проектирования целевого состояния (TO-BE).
Рисунок 2 – Контекстная диаграмма процесса AS IS в нотации IDEF0
Модель AS-IS (рисунок 2) описывает текущее состояние процесса формирования технического задания в университете с точки зрения сотрудника кафедры информационных систем или научного руководителя, ответственного за координацию процесса подготовки ВКР. Эта точка зрения выбрана, так как именно эти специалисты координируют процесс, видят его системные изъяны и несут ответственность за его итоговый результат. Контекст процесса рассматривается как единый функциональный блок «Подготовить и согласовать техническое задание», который взаимодействует с внешней средой через четко определенные интерфейсы.
Основой для запуска процесса служат входные данные – первоначальная идея или задание от научного руководителя, фиксирующее потребность в разработке программного обеспечения для ВКР, а также начальные, зачастую неформализованные, требования заказчика. Процесс жестко регламентируется внешним стандартом ГОСТ 34.602-2020, который определяет структуру и содержание документа. Однако на практике это управляющее воздействие зачастую нивелируется внутренними факторами – использование устаревших локальных шаблонов и специфических требований учебного процесса к выпускным квалификационным работам, что приводит к отклонениям от эталона.
Ключевым ограничивающим фактором являются используемые механизмы. Основную работу по созданию черновика выполняет инициатор – студент. Далее документ проходит проверку и правки у научного руководителя, а финальное утверждение остается за заведующим кафедрой. Весь этот многоступенчатый процесс обеспечивается примитивным набором инструментов: текстовым редактором MS Word для создания и правок, электронной почтой для рассылки и согласования, а иногда и физическими носителями для передачи файлов. Эта разрозненность инструментов порождает главные проблемы процесса.
Результатом работы являются два выхода. Целевым результатом выступает утвержденное техническое задание – официальный документ в стандартном формате. Однако побочным, не менее значимым продуктом становится так называемый архив версий и комментариев – хаотичная коллекция файлов с противоречивыми правками и переписка в почте. Этот «архив» является прямым следствием ручного управления версиями и отсутствия единой среды для работы, превращаясь из полезного инструмента контроля в источник путаницы и потери информации.
Более подробно процесс рассмотрен на диаграмме декомпозиции А0 (рисунок 3).
Процесс начинается с того, что инициатор – студент – получает задание на разработку от научного руководителя. Имея на руках лишь общую идею и набор разрозненных пожеланий, он открывает текстовый редактор и, пытаясь следовать требованиям ГОСТ и внутренним шаблонам, в одиночку создает первый черновик технического задания. При этом, до 48% времени автора тратится не на содержание, а на техническое оформление в MS Word, а используемые шаблоны лишь в 25% случаев соответствуют актуальному ГОСТ 34.602-2020. Созданный файл становится отправной точкой для дальнейших согласований.
Рисунок 3 – Диаграмма декомпозиции процесса А0
Далее документ попадает в сложный и плохо управляемый цикл согласований. Автор рассылает черновик по электронной почте научному руководителю. Руководитель может править прямо в файле или отправлять комментарии ответным письмом. Автору приходится вручную собирать все эти правки в новый вариант документа, зачастую теряя суть замечаний и создавая всё новые версии файлов с путаными названиями. Этот этап, который в среднем повторяется 3,8 раза, растягивая общую длительность процесса до 12,4 календарных дней, превращается в череду уточняющих писем и повторных рассылок, где статус документа и список выполненных правок отслеживаются только в памяти участников.
После того как научный руководитель подтверждает, что документ готов, финальная версия файла направляется заведующему кафедрой для утверждения. Утверждающее лицо, получив документ по электронной почте, ставит визу, после чего техническое задание считается готовым. Формально цель достигнута – на выходе есть утвержденный файл. Однако побочным продуктом этой работы становится хаотичный цифровой след: десятки версий документа в почтовых ящиках разных людей, цепочки писем с комментариями, которые уже не привязаны к конкретным разделам. Этот «архив» не структурирован и зачастую утерян, что в 100% случаев создает риск потери данных и в 75% случаев делает невозможным оперативное восстановление полной истории согласования.
Таким образом, существующий процесс, несмотря на свою кажущуюся простоту, страдает от фундаментальных проблем – информация течет по разорванным каналам, согласование лишено четкого регламента, а контроль версий существует лишь в виде хаоса файлов. Эта модель, построенная на ручных операциях и устаревших инструментах, не только потребляет неоправданно много времени, но и создает риски ошибок и потери данных, что делает её идеальным кандидатом для глубокой автоматизации. Сформулированные на основе полученных метрик цели задают четкий вектор для проектирования целевого состояния TO-BE.
Сбор и анализ требований пользователей к системе автоматизации
Сбор и системный анализ требований будущих пользователей является критически важным этапом проектирования, так как позволяет перевести абстрактную идею автоматизации в конкретный набор функций, которые система обязана выполнять. В случае с веб-сервисом по формированию технических заданий для выпускных квалификационных работ целевая аудитория неоднородна и включает представителей различных ролей, каждая со своими уникальными задачами и потребностями. Для выявления этих потребностей применялся метод анализа типовых рабочих сценариев с ключевыми стейкхолдерами процесса, а также результаты опроса студентов, проведенного в рамках анализа модели AS-IS.
В результате анализа были выделены три основные группы пользователей, чьи интересы и требования к системе кардинально различаются:
Исполнитель / Автор ТЗ (Студент выпускного курса). Для данной группы приоритетом является простота и скорость на начальном этапе. Их ключевая потребность – минимизировать усилия на формальное оформление документа и максимально сосредоточиться на его содержательной части. Они заинтересованы в наличии интуитивно понятного пошагового конструктора, который на основе выбранного типа работы автоматически загрузит соответствующий шаблон ГОСТ 34.602-2020 с уже предзаполненными структурными разделами. Для них критически важна возможность сохранять черновики, получать пошаговые подсказки по заполнению полей, а также иметь простой и ясный механизм отправки документа на проверку научному руководителю, без необходимости разбираться в сложной иерархии согласующих лиц.
Эксперт / Руководитель (Научный руководитель, преподаватель кафедры). Основная задача этой группы – осуществлять содержательный контроль и корректировку документа. Их требования сфокусированы на эффективности процесса рецензирования. Им необходим единый интерфейс, где отображаются все направленные им на проверку документы от их студентов с четкими сроками и статусами. Наибольшую ценность представляет инструмент комментирования, позволяющий оставлять замечания не в общем тексте письма, а привязанными к конкретному абзацу или полю ТЗ, что обеспечивает контекстность обратной связи. Также они нуждаются в возможности либо утвердить документ, либо отправить его на доработку одним кликом, с обязательным указанием причины, и в уведомлениях о новых версиях документа после правок студента.
Администратор процесса (Заведующий кафедрой, сотрудник учебно-методического отдела). Эта группа выступает в роли владельца и контролера процесса в целом. Их требования носят административный и аналитический характер. Им необходимы инструменты для управления системой: создание и актуализация шаблонов ТЗ, настройка маршрутов согласования для разных типов проектов (ВКР, научно-исследовательские работы), регистрация новых пользователей (научных руководителей, студентов) и назначение им ролей. Важнейшим требованием является получение сводной аналитики: панель управления с отчетами о количестве ТЗ на различных стадиях, о средней длительности согласования, о загрузке научных руководителей и просроченных задачах. Для них также важен функционал финального утверждения и архивации завершенных документов с возможностью контекстного поиска по всему архиву.
Выявленные потребности были формализованы, структурированы и разделены на категории согласно стандартной практике разработки требований к программному обеспечению.
Функциональные требования определяют, что именно система должна делать. К ним относятся:
регистрация и аутентификация пользователей с разграничением прав по ролям (студент, научный руководитель, заведующий кафедрой, администратор);
CRUD-операции (создание, чтение, обновление, удаление) для сущностей «Проект (ВКР)» и «Техническое задание»;
работа с библиотекой шаблонов ТЗ, структурированных по разделам ГОСТ 34.602-2020;
реализация workflow (маршрута согласования) по схеме «студент → научный руководитель → заведующий кафедрой» с назначением задач, уведомлениями и изменением статусов;
система контекстных комментариев и история изменений документа;
генерация итогового документа в форматах .docx и .pdf;
формирование стандартных отчетов для администратора (заведующего кафедрой).
Нефункциональные требования описывают, как система должна выполнять свои функции, задавая критерии качества:
Интерфейс должен быть интуитивно понятным для неподготовленного пользователя (студента). Оценка – достижение базовой компетенции работы с системой за время не более 15 минут.
Система должна обеспечивать сохранность данных и иметь механизм автоматического резервного копирования. Целевое время доступности (uptime) – не менее 99% в рабочее время.
Время отклика системы на стандартные операции (загрузка страницы, сохранение черновика) не должно превышать 3 секунд при одновременной работе до 50 пользователей.
Аутентификация и авторизация: хранение паролей только в хешированном виде (алгоритм bcrypt или PBKDF2 с солью); разграничение доступа на основе ролей (RBAC); защита от подбора паролей: блокировка учетной записи на 15 минут после 5 неудачных попыток входа. Защита веб-приложения: встроенные механизмы Django должны обеспечивать защиту от типовых уязвимостей (CSRF-токены, защита от XSS, параметризованные запросы ORM для защиты от SQL-инъекций). Защита персональных данных (152-ФЗ): получение явного согласия пользователя на обработку персональных данных при регистрации; обеспечение конфиденциальности при передаче (использование HTTPS); разграничение доступа (пользователь имеет доступ только к своим персональным данным и данным проектов, в которых он участвует); журналирование всех действий с персональными данными; возможность удаления учетной записи и всех связанных персональных данных по запросу пользователя. Аудит: все значимые действия пользователей должны автоматически фиксироваться в журнале событий с указанием пользователя, времени, типа действия, идентификатора сущности и IP-адреса.
Для управления разработкой требования были приоритизированы по методу MoSCoW:
Must have (Обязательно). Аутентификация, конструктор ТЗ по шаблону ГОСТ, процесс согласования по схеме «студент → руководитель → зав. кафедрой» с комментариями, экспорт в .docx, базовое разграничение прав.
Should have (Желательно). Панель администратора с отчетами, уведомления по электронной почте, расширенная история изменений.
Could have (Возможно). Интеграция с ЭИОС университета, мобильная адаптация интерфейса, импорт данных из существующих файлов.
Won't have (Не сейчас). Встроенный мессенджер, сложные аналитические дашборды с прогнозированием.
В соответствии с принципами инженерии требований, каждое нефункциональное требование должно сопровождаться конкретной метрикой и методом его проверки. Для разрабатываемого веб-сервиса определены следующие верифицируемые показатели качества (таблица 1).
Таблица 1
Метрики качества и методы верификации
Таким образом, проведенный сбор и анализ требований позволил перейти от общего понимания проблемы «нужно автоматизировать» к четкому и измеримому техническому заданию на проектирование системы, которое фокусируется на решении конкретных задач реальных пользователей (студентов, научных руководителей и заведующего кафедрой), обеспечивая практическую ценность и внедряемость будущего веб-сервиса.
Оценка ИТ-инфраструктуры кафедры информационных систем для развертывания веб-сервиса
Оценка существующей ИТ-инфраструктуры является ключевым этапом, определяющим техническую осуществимость и оптимальный сценарий внедрения проектируемого веб-сервиса «ТехЗадание-Конструктор». Анализ материально-технической базы кафедры информационных систем ЧОУ ВО «МУ им. С.Ю. Витте», проведенный на основе данных об оборудованных учебных кабинетах, позволяет сделать выводы о достаточном технологическом потенциале для размещения и эксплуатации системы.
Материально-техническое обеспечение кафедры демонстрирует высокий уровень оснащенности. В распоряжении подразделения находятся несколько специализированных лабораторий (компьютерных классов). Каждый класс оборудован парком персональных компьютеров для обучающихся и преподавателя, объединенных в локальную сеть, что создает готовую среду для развертывания серверного оборудования и тестирования клиентской части веб-приложения. Наличие мультимедийных комплексов (проектор, экран) указывает на возможность проведения презентаций и обучения работе с новой системой. Принципиально важным является тот факт, что все перечисленные помещения адаптированы для использования инвалидами и лицами с ограниченными возможностями здоровья, что автоматически закладывает требование доступности (accessibility) в интерфейс разрабатываемого веб-сервиса.
Анализ программного обеспечения выявляет наиболее значимый для проекта аспект инфраструктуры. На всех компьютерах кафедры установлен согласованный и релевантный стек технологий, который создает благоприятную среду для разработки и запуска системы.
Серверный стек: присутствие Apache, PostgreSQL и MariaDB свидетельствует о наличии опыта развертывания и администрирования веб-серверов и реляционных баз данных. Это прямо соответствует выбранной для проекта архитектуре (Python/Django с СУБД MySQL). Наличие VirtualBox позволяет создавать изолированные тестовые среды и стенды для отладки системы перед промышленным внедрением.
Инструменты разработки: установленные Python, PyCharm Community Edition, Git, Apache NetBeans и VSCodium формируют полноценную среду для разработки бэкенда и фронтенда веб-сервиса. Это подтверждает, что с технической точки зрения процесс создания системы будет обеспечен необходимым лицензионным ПО.
Операционные системы и безопасность: использование антивирусного решения Kaspersky Endpoint Security в составе централизованной консоли администрирования (Kaspersky Security Center) указывает на выстроенную политику информационной безопасности в университете, что накладывает на разрабатываемый веб-сервис обязательные требования по защите персональных данных и устойчивости к типовым угрозам.
Наличие клиентов для работы с системами контроля версий (Git, GitHub Desktop) и офисным пакетом с открытым кодом (OnlyOffice) косвенно указывает на культуру работы с облачными и сетевыми сервисами, что упрощает внедрение нового веб-приложения.
На основе проведенного анализа можно сформулировать, что ИТ-инфраструктура кафедры информационных систем является современной и достаточной для реализации проекта.
Выбор технологического стека для веб-сервиса целесообразно основывать на уже используемом на кафедре ПО: бэкенд на Python (Django), СУБД MySQL, веб-сервер Apache или Nginx. Это минимизирует затраты на обучение и интеграцию.
Таким образом, текущая ИТ-инфраструктура не только не создает барьеров для внедрения, но и предоставляет готовый набор инструментов и среду для успешной разработки, тестирования и первоначальной эксплуатации автоматизированной системы формирования технических заданий.
Перечень служебных поручений и задач при прохождении производственной практики
В соответствии с профилем подготовки и индивидуальным заданием на преддипломную практику руководителем практики от кафедры информационных систем были сформулированы и успешно выполнены следующие служебные поручения и задачи, направленные на сбор материала и реализацию прототипа для выпускной квалификационной работы:
Изучить организационную структуру, нормативно-правовую базу и ИТ-инфраструктуру ЧОУ ВО «Московский университет им. С.Ю. Витте»;
Выбрать, проанализировать и формализовать целевой бизнес-процесс для автоматизации;
Провести сбор, анализ и систематизацию функциональных требований пользователей к разрабатываемой системе;
Разработать и оформить Техническое задание (ТЗ) на создание веб-сервиса «ТехЗадание-Конструктор» в соответствии со стандартом ГОСТ 34.602-2020;
Спроектировать архитектуру веб-сервиса и осуществить инфологическое и логическое проектирование базы данных (БД);
Создать и настроить Git-репозиторий проекта в системе GitFlic для управления версиями исходного кода и ведения истории разработки;
Разработать визуальные прототипы (макеты) ключевых интерфейсов веб-сервиса, соответствующие концепции «конструктора документов» и современным стандартам UI/UX;
Реализовать работоспособный прототип веб-сервиса, включая базовую функциональность;
Подготовить итоговый отчет по результатам прохождения преддипломной практики, отражающий полный объем проделанной работы, и оформить его в соответствии с установленными требованиями.
Все перечисленные задачи были выполнены в установленные сроки и в полном объеме, что позволило сформировать содержательную основу для выпускной квалификационной работы и подтвердить развитие профессиональных компетенций, указанных в индивидуальном задании.
Техническое задание на разработку веб-сервиса автоматизированного формирования ТЗ
Общие сведения
Полное наименование автоматизированной системы (АС): «Веб-сервис автоматизированного формирования и согласования технических заданий».
Условное обозначение: ВС-АФТЗ.
Шифр темы (шифр ВКР): отсутствует.
Заказчик АС: частное образовательное учреждение высшего образования «Московский университет имени С.Ю. Витте» (ЧОУ ВО «МУ им. С.Ю. Витте»), в лице кафедры информационных систем.
Разработчик АС: студент Боровский Сергей Борисович.
Основание для создания АС: индивидуальное задание на прохождение преддипломной практики от 24.11.2025 г. по теме выпускной квалификационной работы «Разработка системы для автоматизированного формирования технического задания в соответствии с ГОСТ».
Плановые сроки выполнения работ: начало работ – 01.12.2025 г. Окончание работ (представление прототипа) – 28.12.2025 г.
Источники и порядок финансирования: работы по созданию веб-сервиса выполняются в рамках прохождения преддипломной практики и подготовки выпускной квалификационной работы. Финансирование не предусмотрено.
Цели и назначение создания автоматизированной системы
Цели создания АС:
сократить среднее время цикла подготовки и согласования технического задания (ТЗ) на разработку программного обеспечения не менее чем на 40% по сравнению с существующим ручным процессом;
обеспечить 100% соответствие оформления выходных документов требованиям ГОСТ 34.602-2020;
повысить прозрачность процесса согласования за счет автоматического контроля статусов и фиксации всех действий пользователей;
ликвидировать потерю актуальных версий документов и обеспечить централизованное хранение полной истории изменений всех ТЗ.
Назначение АС: веб-сервис предназначен для автоматизации деятельности по созданию, согласованию, утверждению и архивации технических заданий на разработку программного обеспечения и автоматизированных систем, выполняемой сотрудниками и обучающимися ЧОУ ВО «МУ им. С.Ю. Витте». Система обеспечивает поддержку полного жизненного цикла документа.
Характеристика объектов автоматизации
Объектом автоматизации является бизнес-процесс «Подготовки, согласования и утверждения технического задания на разработку программного обеспечения для нужд университета». Процесс характеризуется участием нескольких ролей (Инициатор/Автор, Эксперт/Руководитель, Утверждающее лицо), длительным итерационным циклом согласования, использованием разрозненных шаблонов и средств коммуникации (электронная почта, файловые хранилища).
Основные проблемы процесса – высокая трудоемкость, непрозрачность, риск потери версий и несоблюдение стандартов оформления.
Процесс выполняется в условиях локальной вычислительной сети университета с доступом в сеть Интернет.
Требования к автоматизированной системе
Требования к структуре АС в целом: АС должна быть построена по клиент-серверной архитектуре с использованием веб-технологий. Система должна включать серверную часть (бэкенд), базу данных и клиентскую часть (фронтенд), доступную через веб-браузер.
Требования к функциям (задачам), выполняемым АС:
аутентификация и авторизация пользователей с разграничением прав по ролям: «Автор», «Эксперт», «Администратор»;
управление библиотекой шаблонов ТЗ, структурированных по разделам ГОСТ 34.602-2020 (функция администратора);
создание нового проекта ТЗ на основе выбранного шаблона с использованием интерфейса «конструктора» (заполнение, добавление вложений);
организация маршрута согласования с назначением задач, автоматическими уведомлениями и контролем сроков;
возможность оставления контекстных комментариев (привязанных к разделам ТЗ) экспертами;
хранение полной истории изменений документа (версионность);
экспорт утвержденного ТЗ в форматы .docx и .pdf;
формирование отчетов для администратора (статистика по проектам, загрузка экспертов).
Требования к видам обеспечения АС:
техническое обеспечение: сервер с ОС Linux/Windows, веб-сервер (Apache/Nginx), СУБД MySQL 8.0 и выше, интерпретатор Python 3.9 и выше;
программное обеспечение: фреймворк Django, библиотеки для генерации документов (python-docx);
информационное обеспечение: база данных должна содержать не менее 10 таблиц согласно разработанной схеме (раздел 2.5); обмен данными между клиентом и сервером должен осуществляться по протоколу HTTPS с использованием шифрования TLS 1.2/1.3; форматы данных: JSON – для API-взаимодействия, HTML – для отображения страниц.;
лингвистическое обеспечение: пользовательский интерфейс на русском языке;
организационное обеспечение: инструкция пользователя и администратора системы.
Общие технические требования к АС:
надежность – система должна обеспечивать целостность данных при любых сценариях завершения работы пользователя (закрытие вкладки, потеря соединения). Реализуется через автоматическое сохранение черновиков на стороне сервера; должно быть реализовано автоматическое резервное копирование базы данных с периодичностью не реже 1 раза в сутки и хранением не менее 7 последних копий; время восстановления системы после сбоя – не более 4 часов; точка восстановления данных – не более 24 часов (потери данных не более чем за сутки);
производительность – время отклика на стандартные операции (загрузка страницы, сохранение) не должно превышать 3 секунд при одновременной работе до 50 пользователей. Методика проверки – нагрузочное тестирование с использованием инструмента JMeter или Locust на тестовом стенде, идентичном по характеристикам продуктивному серверу;
безопасность – обязательное шифрование паролей, защита от SQL-инъекций и межсайтовой подделки запросов (CSRF). Доступ к функциям – строго в соответствии с ролью пользователя;
эргономика – интерфейс должен быть интуитивно понятным. Оценка – освоение базовых функций новым пользователем в течение 15 минут без дополнительного обучения.
Состав и содержание работ по созданию автоматизированной системы
Этап 1. Подготовительный (01.12.2025 – 07.12.2025): Анализ требований, разработка и согласование настоящего ТЗ, проектирование архитектуры и БД.
Этап 2. Реализация прототипа (08.12.2025 – 21.12.2025): Разработка серверной и клиентской частей системы, реализация базового функционала (управление пользователями, конструктор ТЗ, простое согласование).
Этап 3. Тестирование и отладка (22.12.2025 – 26.12.2025): Проведение модульного, интеграционного и приемочного тестирования, устранение выявленных ошибок.
Этап 4. Документирование и подготовка к защите (27.12.2025 – 28.12.2025): Написание руководства пользователя, подготовка презентации и демонстрационных материалов, оформление отчета по практике.
Порядок разработки автоматизированной системы
Разработка ведется студентом-исполнителем с периодическим контролем со стороны руководителя практики от университета. Исходными данными являются требования, изложенные в разделах 1.4 и 1.7.4 отчета о преддипломной практике, а также модель бизнес-процесса AS-IS. По окончании каждого этапа представляется соответствующий результат (ТЗ, рабочий прототип, отчет по тестированию). Экспертиза технической документации (кода, схем БД) проводится руководителем. Гарантийные обязательства разработчика включают устранение критических ошибок, обнаруженных в течение месяца после сдачи прототипа.
Порядок контроля и приемки автоматизированной системы
Приемка работ будет проводиться в форме демонстрации работоспособного прототипа и защиты отчета по практике. Испытания включают:
функциональное тестирование на соответствие требованиям раздела 1.7.4;
смоук-тестирование критического пути (создание, согласование, утверждение ТЗ);
тестирование безопасности на уровне доступов.
Приемочной комиссией является комиссия по защите отчетов по практике кафедры информационных систем.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу автоматизированной системы в действие
Для опытной эксплуатации прототипа необходимо:
выделить тестовый сервер в ИТ-инфраструктуре кафедры, соответствующий требованиям п. 1.7.4;
определить круг тестовых пользователей (не менее 3-х человек с разными ролями);
обеспечить ознакомление тестовых пользователей с руководством и проведение краткого инструктажа.
Требования к документированию
В процессе и по результатам создания АС должны быть разработаны следующие документы:
Настоящее техническое задание;
Текстовая часть отчета по преддипломной практике с описанием проекта;
Руководство пользователя (в электронном виде);
Исходный код системы с комментариями, размещенный в Git-репозитории.
Источники разработки
ГОСТ 34.602-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Индивидуальное задание на прохождение преддипломной практики студента Боровского С.Б., 2025 г.
Материалы анализа организационной структуры и ИТ-инфраструктуры ЧОУ ВО «МУ им. С.Ю. Витте».
Модель бизнес-процесса AS-IS «Подготовки и согласования ТЗ», разработанная в ходе практики.
Выводы по разделу
В ходе проведения преддипломной практики в ЧОУ ВО «Московский университет им. С.Ю. Витте» был выполнен полный комплекс аналитических и проектных работ в рамках подготовки к разработке выпускной квалификационной работы. Целью данного этапа являлось всестороннее изучение объекта автоматизации, сбор требований и формализация задачи. На основании анализа структуры университета, существующего бизнес-процесса и технологической инфраструктуры, а также в результате выполнения служебных поручений был сформулирован ключевой документ – Техническое задание на разработку веб-сервиса автоматизированного формирования ТЗ. Результаты проделанной работы позволили подтвердить развитие следующих профессиональных компетенций (табл.2):
Таблица 2
Выводы по разделу 1
ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ И КОМПОНЕНТОВ
ВЕБ-СЕРВИСА
Разработка оптимизированной модели бизнес-процесса (модель
TO-BE)
Проектирование оптимизированной модели бизнес-процесса (TO-BE) является прямым результатом анализа проблем, выявленных в модели AS-IS, и формализованных требований пользователей. Новая модель описывает целевое состояние процесса «Подготовки, согласования и утверждения технического задания» после внедрения веб-сервиса «ТехЗадание-Конструктор». Ее цель – наглядно продемонстрировать, как автоматизация устраняет ключевые узкие места, обеспечивая прозрачность, управляемость и сокращение времени цикла. Для формализации целевого процесса также используется методология IDEF0, что позволяет провести прямое сравнение с исходной моделью и четко обозначить произошедшие изменения.
Рисунок 4 – Процесс TO BE в нотации IDEF0. Контекстная диаграмма
Контекстная диаграмма (Диаграмма A-0) рассматривает целевой процесс как единый функциональный блок, интегрированный в новую цифровую среду (рисунок 4).
Диаграмма декомпозиции первого уровня (Диаграмма A0) раскрывает внутреннюю структуру автоматизированного процесса, показывая, как веб-сервис трансформирует последовательность шагов (рисунок 5).
Рисунок 5 – Диаграмма декомпозиции процесса TO BE
Процесс инициируется, когда пользователь регистрирует в системе новую потребность (идея или заявка). В отличие от модели AS-IS, на этапе «Создать проект и черновик ТЗ в конструкторе» он работает не с изолированным файлом, а со встроенным в веб-сервис инструментом. Система предоставляет ему структурированные шаблоны, жестко соответствующие ГОСТ 34.602-2020, что исключает ошибки форматирования. Введенные данные сразу сохраняются как «Созданный проект» в СУБД, создавая первую версию. Все действия выполняются в рамках единого веб-сервиса.
Далее автор запускает этап «Запустить и контролировать процесс согласования», который принципиально отличается от старого. Вместо ручной рассылки писем система автоматически, согласно регламенту workflow, назначает задачи соответствующим экспертам в их личные кабинеты. Эксперты изучают документ в едином интерфейсе и оставляют комментарии, привязанные к конкретным разделам. Автор видит все замечания в одном месте и вносит правки прямо в системе. Статус документа («Черновик», «На согласовании», «Требует доработки», «Готово к утверждению») изменяется автоматически и виден всем участникам. Цикл правок происходит внутри одного блока A2 за счет изменения состояния документа (ТЗ на согласовании), без создания новых файловых версий.
После завершения согласования документ переходит в статус ТЗ готово к утверждению. На этапе «Завершить проект: утвердить и экспортировать» утверждающее лицо знакомится с документом и всеми комментариями прямо в системе и нажимает кнопку «Утвердить». Это действие фиксируется в системе. После утверждения система позволяет сгенерировать «Утвержденное техническое задание» в формате .docx или .pdf, гарантированно соответствующее ГОСТ. Весь «Цифровой архив проекта», включая все версии, комментарии, историю статусов и действий пользователей, остается структурированно храниться в базе данных, обеспечивая полную аудируемость и доступность для поиска.
Таким образом, модель TO-BE демонстрирует переход от разрозненного, файло-ориентированного и ручного процесса к централизованному, управляемому данными и автоматизированному workflow. Ключевыми изменениями являются ликвидация пересылки файлов, введение автоматического контроля потока работ, обеспечение единого источника истины для документа и структурированное хранение всей сопутствующей информации.
Проектирование архитектуры веб-сервиса «ТехЗадание-Конструктор»
Архитектура проектируемого веб-сервиса «ТехЗадание-Конструктор» строится на основе клиент-серверной модели и принципов многослойной (N-слойной) архитектуры. Такой подход обеспечивает четкое разделение ответственности между компонентами, что повышает надежность, сопровождаемость и масштабируемость системы.
Для объективного выбора технологической платформы был проведен сравнительный анализ трех наиболее релевантных вариантов, способных обеспечить реализацию требуемого функционала в рамках образовательного учреждения. Критерии сравнения выбраны исходя из требований к системе, характеристик ИТ-инфраструктуры кафедры и потенциальных потребностей интеграции (табл. 3).
Таблица 3
Сравнение стеков для разработки системы
Продолжение Таблицы 2
На основе проведенного сравнительного анализа для реализации веб-сервиса «ТехЗадание-Конструктор» был выбран стек на базе Python и веб-фреймворка Django. Данное решение продиктовано описываемыми далее факторами:
Как было показано в разделе 1.5, во всех компьютерных классах кафедры информационных систем предустановлены Python, PyCharm, Git и Apache. Это означает, что среда разработки и развертывания уже готова и не требует дополнительных согласований с Департаментом информационных технологий на установку нового программного обеспечения. Любой студент или преподаватель может сразу приступить к работе с системой без предварительной настройки окружения.
Django предоставляет «батарейки» – готовые решения для типовых задач веб-разработки:
Встроенная админ-панель автоматически создается на основе моделей данных, что позволяет администратору управлять пользователями, шаблонами и справочниками без написания дополнительного кода.
Встроенная ORM (Object-Relational Mapping) абстрагирует работу с базой данных MySQL, обеспечивая безопасность (защиту от SQL-инъекций) и удобство разработки.
Готовая система аутентификации и авторизации позволяет быстро реализовать разграничение прав по ролям (администратор, руководитель, автор).
Python является основным языком программирования, изучаемым студентами направления «Бизнес-информатика» и смежных IT-специальностей. Выбор Django обеспечивает возможность дальнейшего развития и поддержки системы силами студентов и выпускников кафедры без привлечения внешних специалистов, что критически важно для образовательного учреждения.
Хотя Django не является асинхронным по умолчанию, для заявленных нагрузок (до 50-100 одновременных пользователей) его производительности более чем достаточно. В случае роста числа пользователей, Django-приложение легко масштабируется горизонтально за счет:
Использования кэширования (Redis, Memcached).
Балансировки нагрузки между несколькими серверами приложений.
Оптимизации запросов к базе данных.
Django не ограничивает выбор технологии для клиентской части. Он может работать в двух режимах:
Использование встроенного шаблонизатора Django Templates для быстрого создания прототипа интерфейса. Этот подход выбран для первоначальной версии системы.
В будущем Django может выступать в роли бэкенда, отдающего данные в формате JSON, а фронтенд может быть реализован на любом современном JavaScript-фреймворке (React, Vue.js) для создания более динамичного и отзывчивого интерфейса.
Django имеет богатую экосистему пакетов для интеграции с внешними системами:
django-auth-ldap – для интеграции с корпоративным каталогом Active Directory университета (при наличии).
django-rest-framework – для создания API, которое может быть использовано для интеграции с ЭИОС «Электронный университет» или другими сервисами.
django-cors-headers – для обеспечения безопасного взаимодействия с другими доменами.
Node.js + Express обеспечивает высокую производительность и асинхронность, а также отлично сочетается с современными JavaScript-фреймворками. Однако он не присутствует в стандартном программном обеспечении компьютерных классов кафедры, что потребовало бы дополнительных административных согласований на установку. Кроме того, язык JavaScript (особенно в асинхронной парадигме) менее привычен для студентов, что, возможно, осложнило бы поддержку системы в будущем.
Java + Spring Boot – промышленный стандарт для крупных корпоративных систем, обеспечивающий наивысшую надежность и масштабируемость. Однако для задач автоматизации процесса формирования ТЗ его использование является избыточным. Высокий порог вхождения, значительный объем шаблонного кода и более высокие требования к ресурсам делают этот стек неоптимальным для университетского проекта, где приоритетом является быстрота разработки и простота поддержки.
Таким образом, в качестве базового технологического стека выбран Python с веб-фреймворком Django для серверной части, СУБД MySQL для хранения данных и стандартный набор HTML, CSS, JavaScript для клиентской части. Этот стек оптимально соответствует требованиям проекта, возможностям ИТ-инфраструктуры кафедры и позволяет реализовать функционал с минимальными накладными расходами.
Сервис будет реализовывать все сценарии, описанные в модели TO-BE, через взаимодействие трех основных логических слоев:
уровень представления (Presentation Layer): Веб-интерфейс, доступный пользователям через браузер. Отвечает за отображение форм, конструктора ТЗ, панелей управления и взаимодействие с пользователем;
Рисунок 6 – Дерево функций веб-сервиса
уровень бизнес-логики (Business Logic Layer): Серверное ядро на Django. Обрабатывает запросы от клиента, выполняет проверки, управляет бизнес-процессами (workflow согласования), формирует документы и взаимодействует с базой данных;
уровень доступа к данным (Data Access Layer): Слой, ответственный за сохранение и извлечение информации. Реализуется через объектно-реляционное отображение (ORM Django), которое абстрагирует работу с СУБД MySQL.
Для наглядного представления функциональных возможностей системы строится дерево функций (рисунок 6), которое декомпозирует основную задачу сервиса на иерархию подфункций.
Для описания физической структуры системы и взаимодействия ее составных частей используется диаграмма компонентов UML (рисунок 7). Она показывает ключевые программные модули, их интерфейсы и зависимости.
Пользователь взаимодействует с системой через Веб-браузер, где загружается клиентское приложение (на основе шаблонов Django). Все запросы пользователя по протоколу HTTP/HTTPS поступают на Веб-сервер (Nginx или Apache), который выполняет роль обратного прокси и сервера статических файлов.
Основная нагрузка ложится на Приложение Django, являющееся ядром системы. Входящие запросы перенаправляются веб-сервером через интерфейс WSGI к соответствующим Контроллерам. Контроллеры извлекают данные из запроса, валидируют их и делегируют выполнение бизнес-логики соответствующим Службам. Например, «Служба проектов» управляет созданием и сохранением черновиков, «Служба workflow» – движком согласования и уведомлений, «Служба документов» – генерацией файлов .docx.
Все службы работают с данными через Модели, которые являются объектным представлением таблиц базы данных. Для взаимодействия с СУБД MySQL используется ORM Django. Она транслирует операции с объектами Python в SQL-запросы, обеспечивая безопасность (защита от инъекций) и абстракцию от конкретной СУБД. Данные всех сущностей – пользователи, проекты, версии ТЗ, комментарии, шаблоны – хранятся в соответствующих таблицах.
Рисунок 7 – Диаграмма компонентов веб-сервиса «ТехЗадание-Конструктор»
Для отправки автоматических уведомлений о новых задачах или комментариях Служба workflow взаимодействует с внешним SMTP-сервером по протоколу электронной почты. Такое построение архитектуры обеспечивает модульность: каждый компонент отвечает за свою узкую задачу, что упрощает разработку, тестирование и возможное будущее расширение системы.
Составление плана разработки
План разработки веб-сервиса «ТехЗадание-Конструктор» составлен на основе технического задания и с учетом сроков прохождения преддипломной практики (01.12.2025 – 28.12.2025). Основной целью плана является структурирование работ, обеспечение пошагового достижения целей и эффективный контроль за ходом реализации проекта.
Разработка разделена на четыре последовательных этапа, в рамках которых поэтапно создаются и интегрируются компоненты системы: от проектирования и настройки среды до тестирования и подготовки к защите. Каждый этап имеет конкретные задачи, планируемые результаты, ответственных исполнителей и контрольные точки. Руководство проектом и приемка результатов осуществляется руководителем практики от университета, в то время как основную исполнительскую роль выполняет студент-разработчик.
Для наглядного представления временных рамок и параллельности работ план визуализирован в виде диаграммы Ганта (рисунок 8).
План реализуется по итеративному принципу. Еженедельно проводится сверка текущего состояния с планом и демонстрация промежуточных результатов руководителю. Все артефакты (код, схемы, документация) размещаются в Git-репозитории, что обеспечивает контроль версий и прозрачность процесса. Критерием успешного завершения каждого этапа является достижение запланированных результатов, подтвержденное руководителем. Финальным контрольным мероприятием является защита отчета по практике с демонстрацией работоспособного прототипа системы.
Рисунок 8 - План разработки веб-сервиса «ТехЗадание-Конструктор»
Настройка репозитория управления проектом
Настройка репозитория управления проектом является важнейшим организационным этапом, который закладывает основу для ведения всего процесса разработки. Для хранения исходного кода, отслеживания истории изменений и командной работы был выбран сервис GitFlic – отечественная альтернатива GitHub, которая рекомендована для использования в учебных проектах. Работа с системой контроля версий Git начинается с локальной настройки и последовательно переносится в удалённое облачное хранилище.
Первым делом, на компьютере разработчика была установлена и настроена система Git. После установки необходимо было представиться системе, указав своё имя и электронную почту, которые будут фиксироваться в истории всех коммитов. Это было сделано с помощью следующих команд в терминале:
git config --global user.name "Сергей Боровский"
git config --global user.email "70197535@online.muiv.ru"
Далее, в корневой папке проекта «ТехЗадание-Конструктор» была выполнена ключевая команда git init. Эта команда создала скрытую папку .git, в которой Git начал отслеживать все изменения файлов проекта, превратив обычную директорию в полноценный локальный репозиторий.
Следующим шагом стало создание удалённого (remote) репозитория, выступающего в роли централизованного и доступного из любого места хранилища. На сайте GitFlic.ru после регистрации и входа в личный кабинет был создан новый публичный проект. Ему было дано название, соответствующее теме работы: auto_tech_spec. После создания платформа предоставила уникальный URL-адрес для этого репозитория. Чтобы связать локальную папку проекта с этим удалённым хранилищем, использовалась команда:
git remote add origin https://gitflic.ru/project/borovskiy/auto_tech_spec.git
Здесь origin – это стандартное условное имя для основной удалённой ссылки, а URL – это адрес, который нужно скопировать со страницы вашего проекта на GitFlic.
Основная работа теперь строится вокруг простого цикла команд. После внесения изменений в код или добавления новых файлов, их необходимо «подготовить к сохранению» с помощью git add:
git add . # Добавляет ВСЕ изменённые файлы в текущей папке и подпапках
# ИЛИ для конкретного файла:
git add README.md main.py
Далее изменения фиксируются в истории с поясняющим сообщением командой git commit:
git commit -m "Добавлена модель пользователя и основа БД"
И, наконец, чтобы отправить все зафиксированные локально изменения на удалённый сервер GitFlic и сделать их доступными, выполняется команда отправки (push):
git push -u origin main
Флаг -u связывает локальную ветку main с удалённой origin/main, и в дальнейшем можно будет использовать просто git push. Этот цикл (add – commit – push) стал основой работы над проектом.
Все исходные коды, история разработки и файлы проекта доступны в публичном репозитории по адресу:
https://gitflic.ru/project/borovskiy/auto_tech_spec
Таким образом, настройка репозитория позволила перейти от хаотичного хранения файлов к структурированному, контролируемому и безопасному процессу разработки. Каждое значимое изменение теперь имеет автора, дату и описание, что полностью соответствует требованиям к ведению проектной документации в рамках преддипломной практики.
Проектирование базы данных
Проектирование базы данных является ключевым этапом разработки веб-сервиса «ТехЗадание-Конструктор», определяющим эффективность хранения, целостность и скорость доступа к данным. База данных реализована на СУБД MySQL 8.0 и включает 13 прикладных таблиц, созданных для нужд системы, а также 9 служебных таблиц, автоматически генерируемых фреймворком Django для обеспечения работы встроенных механизмов аутентификации, авторизации и миграций. Ниже представлено описание структуры, процесса нормализации и физической реализации базы данных.
Инфологическое проектирование БД (ER-диаграмма)
Предметной областью является процесс управления жизненным циклом технических заданий для выпускных квалификационных работ. В результате анализа были выделены ключевые сущности, отражающие как основные бизнес-объекты, так и обеспечивающие их работу.
Основные сущности:
Пользователь (User) – сотрудник или студент университета, работающий в системе. Является центральной сущностью, участвующей во всех процессах.
Проект (Project) – инициируемая работа (ВКР, НИР), для которой создается ТЗ. Один проект связан с одним основным ТЗ.
Техническое задание (TechnicalSpec) – основной документ, создаваемый в системе. Сущность хранит актуальную версию и метаданные документа.
Версия документа (DocumentVersion) – конкретное состояние ТЗ на определенный момент времени. Позволяет хранить полную историю изменений.
Комментарий (Comment) – замечание или правка, оставленная участником согласования к конкретному разделу ТЗ.
Шаблон (Template) – формализованная структура ТЗ по ГОСТ 34.602-2020, на основе которой создаются новые документы.
Дополнительные сущности:
Роль (Role) – определяет права доступа в системе (администратор, автор, рецензент, утверждающий, наблюдатель, исполнитель, контроль качества).
Рисунок 9 – ER-диаграмма
Статус согласования (ApprovalStatus) – этап workflow, в котором находится документ (черновик, на проверке, на согласовании, требует доработки, рекомендовано, утверждено, архив, ожидание финансового отдела, юридическая проверка, отклонено).
Журнал событий (EventLog) – фиксация всех значимых действий пользователей в системе.
Участник проекта (ProjectMember) – ассоциативная сущность, связывающая пользователей с проектами и определяющая их роль в конкретном проекте.
Задача на согласование (ReviewTask) – сущность для управления задачами, назначенными на рецензентов.
Сообщение обратной связи (FeedbackMessage) – сущность для хранения сообщений, отправленных через форму обратной связи.
Отчет (Report) – сущность для хранения сгенерированных аналитических отчетов.
На основе выявленных сущностей и связей между ними построена ER-диаграмма (рисунок 9), отображающая концептуальную модель данных.
Логическое проектирование БД (Уточненная ER-диаграмма)
На этапе логического проектирования каждая сущность была детализирована атрибутами (табл. 4). Особое внимание уделено связям «многие-ко-многим», таким как связь между пользователями и проектами, которая разрешена через ассоциативную сущность project_members. В этой сущности фиксируется роль участника в конкретном проекте (рецензент, утверждающий, исполнитель, наблюдатель). Также уточнены атрибуты, отражающие бизнес-логику: порядковый номер статуса для построения маршрута согласования, ссылка на конкретный раздел в комментарии (section_path), структура шаблона в формате JSON.
Таблица 4
Прикладные таблицы базы данных
Назначение служебных таблиц Django описано в табл. 5:
Таблица 5
Служебные таблицы Django
Разработка схемы данных
На основе уточненной ER-диаграммы разработана схема базы данных, определяющая конкретные таблицы, их столбцы и связи в реляционной модели. Все связи «многие-ко-многим» разрешены через промежуточные таблицы. Для обеспечения ссылочной целостности определены внешние ключи (FOREIGN KEY). Типы данных выбраны в соответствии с возможностями СУБД MySQL 8.0.
Рисунок 11 – Схема данных
Физическое проектирование БД
Составление реляционных отношений
На основе схемы данных составлены реляционные отношения. Всего в прикладной части базы данных 13 таблиц. Ниже приведены основные реляционные отношения.
Таблица 6
Схема отношения users
Таблица 7
Схема отношения projects
Таблица 8
Схема отношения project_members
Таблица 9
Схема отношения templates
Таблица 10
Схема отношения technical_specs
Таблица 11
Схема отношения document_versions
Таблица 12
Схема отношения approval_statuses
Таблица 13
Схема отношения comments
Таблица 14
Схема отношения event_log
Таблица 15
Схема отношения review_tasks
Таблица 16
Схема отношения feedback_messages
Таблица 17
Схема отношения dashboard_report
Таблица 18
Схема отношения roles
Нормализация полученных отношений
Процесс нормализации является итеративным и направлен на устранение избыточности данных и аномалий обновления. Ниже представлен процесс нормализации от исходного ненормализованного представления до нормальной формы Бойса-Кодда (BCNF).
В результате анализа предметной области выявлена совокупность атрибутов, описывающих процесс работы с техническими заданиями. В исходном виде эти атрибуты собраны в одно универсальное отношение, что приводит к избыточности и аномалиям:
Таблица 19
Универсальное отношение «Проект» (ненормализованное)
Выявленные функциональные зависимости:
project_id → project_title, author_login.
author_login → author_name, author_email.
(project_id, user_login) → member_role.
project_id → spec_title.
(spec_id, version_number) → version_content, status_name.
version_id → spec_id, version_number.
(version_id, comment_id) → comment_text, comment_author, comment_date.
status_name → status_description, order_num.
Первая нормальная форма требует атомарности значений и отсутствия повторяющихся групп. Для устранения повторяющихся групп участников проекта и множественных версий/комментариев выделяем отдельные отношения:
Таблица 20
Отношение «Проекты» (1НФ)
Таблица 21
Отношение «Авторы» (1НФ)
Таблица 22
Отношение «Участники проекта» (1НФ)
Таблица 23
Отношение «Технические задания» (1НФ)
Таблица 24
Отношение «Версии документа» (1НФ)
Таблица 25
Отношение «Комментарии» (1НФ)
Таблица 26
Отношение «Статусы» (1НФ)
Таблица 27
Отношение «Роли» (1НФ)
Таблица 28
Отношение «Пользователи» (1НФ)
Таблица 29
Отношение «Шаблоны» (1НФ)
Таблица 30
Отношение «Журнал событий» (1НФ)
Вторая нормальная форма требует, чтобы отношение находилось в 1НФ и каждый неключевой атрибут полностью зависел от первичного ключа (отсутствие частичной зависимости). Проверим каждое отношение:
Отношение «Версии документа»:
Первичный ключ составной (spec_id, version_number).
Атрибут status_name полностью зависит от полного ключа (каждая версия имеет свой статус) – условие 2НФ выполняется.
Атрибут version_content полностью зависит от полного ключа – условие выполняется.
Отношение «Комментарии»:
Первичный ключ составной (version_id, comment_id).
Атрибуты comment_text, comment_author, comment_date полностью зависят от полного ключа – условие 2НФ выполняется.
Отношение «Участники проекта»:
Первичный ключ составной (project_id, user_login).
Атрибут member_role полностью зависит от полного ключа – условие 2НФ выполняется.
Все остальные отношения имеют простые первичные ключи, поэтому для них условие 2НФ выполняется автоматически.
Третья нормальная форма требует отсутствия транзитивных зависимостей (зависимости неключевых атрибутов от других неключевых атрибутов).
Отношение «Проекты»:
Имеет атрибут author_login, который является внешним ключом.
Транзитивная зависимость project_id → author_login → author_name – существует, так как author_name зависит от author_login, а не напрямую от project_id.
Решение: выделить отдельное отношение «Авторы» (уже сделано на этапе 1НФ).
Отношение «Версии документа»:
Имеет атрибут status_name.
Транзитивная зависимость version_id → status_name → order_num – существует, так как order_num зависит от status_name.
Решение: выделить отдельное отношение «Статусы» (уже сделано на этапе 1НФ).
Отношение «Пользователи»:
Имеет атрибут role_name, который является внешним ключом к таблице «Роли».
Транзитивная зависимость user_id → role_name → role_description – существует, так как role_description зависит от role_name.
Решение: выделить отдельное отношение «Роли» (уже сделано на этапе 1НФ) и заменить в таблице users атрибут role_name на внешний ключ role_id.
Нормальная форма Бойса-Кодда требует, чтобы для любой нетривиальной функциональной зависимости X → Y, X являлся суперключом. Проверим каждое отношение:
Отношение «Авторы» (users):
Зависимости user_id → login, full_name, email, role_id.
user_id является первичным ключом (суперключом) – условие BCNF выполняется.
Дополнительная зависимость login → user_id (логин уникален). login также является суперключом (альтернативным ключом) – условие BCNF выполняется.
Отношение «Технические задания» (technical_specs):
Зависимости project_id → spec_id (поскольку project_id уникален для ТЗ).
Введен суррогатный ключ spec_id – первичный ключ. project_id является уникальным альтернативным ключом – условие BCNF выполняется.
Отношение «Версии документа» (document_versions):
Зависимости (spec_id, version_number) → content, status_id, created_by, created_at
(spec_id, version_number) является составным первичным ключом – условие BCNF выполняется.
Дополнительная зависимость version_id → spec_id, version_number (суррогатный ключ). version_id является суперключом – условие BCNF выполняется.
Отношение «Участники проекта» (project_members):
Зависимость (project_id, user_id) → member_role, joined_at
(project_id, user_id) является составным первичным ключом – условие BCNF выполняется.
Отношение «Комментарии» (comments):
Зависимости (version_id, id) → section_path, content, author_id, is_resolved
id является первичным ключом (суррогатным), version_id – внешний ключ.
Зависимость comment_id → version_id, section_path, ... – comment_id является суперключом – условие BCNF выполняется.
Отношение «Шаблоны» (templates):
Зависимости template_id → name, structure, based_on_standard, is_active
template_id является первичным ключом – условие BCNF выполняется.
Дополнительная зависимость name → template_id (название шаблона уникально). name является суперключом – условие BCNF выполняется.
Отношение «Статусы» (approval_statuses):
Зависимости status_id → name, description, order_num, is_final
status_id является первичным ключом – условие BCNF выполняется.
Дополнительная зависимость name → status_id (название статуса уникально). name является суперключом – условие BCNF выполняется.
Дополнительная зависимость order_num → status_id (порядковый номер уникален). order_num является суперключом – условие BCNF выполняется.
Отношение «Роли» (roles):
Зависимости role_id → name, description
role_id является первичным ключом – условие BCNF выполняется.
Дополнительная зависимость name → role_id (название роли уникально). name является суперключом – условие BCNF выполняется.
Отношение «Журнал событий» (event_log):
Зависимости event_id → user_id, project_id, action_type, entity_type, entity_id, timestamp, ip_address, user_agent
event_id является первичным ключом (UUID) – условие BCNF выполняется.
Отношение «Задачи на согласование» (review_tasks):
Зависимости task_id → spec_id, assigned_to_id, status, decision, due_date
task_id является первичным ключом – условие BCNF выполняется.
Отношение «Сообщения обратной связи» (feedback_messages):
Зависимости id → name, email, subject, message, status, created_at
id является первичным ключом – условие BCNF выполняется.
Отношение «Отчеты» (dashboard_report):
Зависимости id → title, report_type, period_start, period_end, data, created_by_id, created_at
id является первичным ключом – условие BCNF выполняется.
Теперь все отношения находятся в нормальной форме Бойса-Кодда (BCNF), что гарантирует:
Отсутствие избыточности данных.
Отсутствие аномалий вставки, обновления и удаления.
Однозначное представление каждой функциональной зависимости.
Полученная нормализованная схема соответствует описанной в разделе 2.5.3 и включает 13 прикладных таблиц, а также 9 служебных таблиц Django, обеспечивающих работу встроенных механизмов аутентификации, авторизации и управления сессиями.
Описание групп пользователей и прав доступа
Для обеспечения информационной безопасности и соответствия бизнес-процессу определены следующие группы пользователей:
Администратор (admin) имеет полный доступ (CREATE, SELECT, INSERT, UPDATE, DELETE) ко всем таблицам. Управляет пользователями, ролями, шаблонами, статусами.
Рецензент / Руководитель (reviewer) может выполнять запросы SELECT на projects, technical_specs, document_versions, templates. INSERT, UPDATE на comments. UPDATE на document_versions (только поле status_id для перевода на следующий этап). Доступ только к проектам, где является участником.
Автор / Исполнитель (author) выполняет SELECT на свои проекты и ТЗ. INSERT на projects, technical_specs. INSERT, UPDATE на document_versions (создание и редактирование черновиков). Доступ только к своим проектам.
Утверждающий (approver) может выполнять запросы SELECT на все проекты, ТЗ, версии. UPDATE на document_versions (финальное утверждение). Доступ к проектам, где назначен как approver.
Наблюдателю (observer) доступны запросы SELECT на проекты, ТЗ, версии, комментарии. Без права записи.
Создание таблиц в базе данных
Физическая реализация базы данных выполнена с помощью DDL-скриптов, приведенных в Приложении 2. Ключевые особенности реализации:
Использование JSON типа данных для полей templates.structure и document_versions.content.
Создание индексов для оптимизации запросов: idx_event_log_user_timestamp, idx_document_versions_spec_created.
Обеспечение ссылочной целостности через FOREIGN KEY с политиками ON DELETE CASCADE, ON DELETE SET NULL, ON DELETE RESTRICT.
Проектирование наиболее востребованных запросов
На основе анализа пользовательских сценариев спроектированы следующие востребованные SQL-запросы (полный список приведен в Приложении 3):
Получение списка активных проектов с информацией о руководителе и количестве участников – используется для дашборда руководителя.
Получение списка всех ТЗ с текущим статусом согласования и количеством комментариев – используется для мониторинга прогресса согласования.
Получение детальной информации по конкретному ТЗ с историей версий – используется при просмотре карточки ТЗ.
Получение всех комментариев к ТЗ, сгруппированных по разделам – используется при согласовании ТЗ.
Получение статистики по пользователям – используется для отчетов по активности.
Получение просроченных проектов и ТЗ – используется для уведомлений о дедлайнах.
Получение журнала действий по проекту или пользователю – используется для аудита.
Установка индексов
Для оптимизации производительности созданы следующие индексы:
-- Индексы для первичных и внешних ключей
CREATE INDEX idx_users_role_id ON users(role_id);
CREATE INDEX idx_projects_author_id ON projects(author_id);
CREATE INDEX idx_project_members_user_id ON project_members(user_id);
CREATE INDEX idx_technical_specs_project_id ON technical_specs(project_id);
CREATE INDEX idx_document_versions_spec_id ON document_versions(spec_id);
CREATE INDEX idx_document_versions_status_id ON document_versions(status_id);
CREATE INDEX idx_comments_version_id ON comments(version_id);
-- Составные индексы для частых запросов
CREATE INDEX idx_document_versions_spec_created ON document_versions(spec_id, created_at DESC);
CREATE INDEX idx_event_log_user_timestamp ON event_log(user_id, timestamp DESC);
Таким образом, спроектированная база данных обеспечивает полное структурированное хранение всех данных, необходимых для функционирования веб-сервиса «ТехЗадание-Конструктор», поддерживает целостность информации, соответствует требованиям информационной безопасности и оптимизирована для выполнения типовых запросов.
Выводы по разделу 2
В ходе проектирования веб-сервиса «ТехЗадание-Конструктор» был выполнен комплекс работ, направленный на формализацию целевого состояния бизнес-процесса, проектирование архитектуры, системы данных и организацию процесса разработки. На основе результатов аналитического раздела была разработана и визуализирована оптимизированная модель бизнес-процесса (TO-BE) в нотации IDEF0, которая наглядно демонстрирует устранение ключевых недостатков исходного процесса за счет внедрения централизованного цифрового workflow. Спроектирована клиент-серверная архитектура системы с использованием технологического стека Python/Django/MySQL, представленная в виде дерева функций и диаграммы компонентов UML, что обеспечивает модульность, масштабируемость и безопасность решения. Выполнено детальное инфологическое, логическое и физическое проектирование реляционной базы данных, включающее построение ER-диаграмм, нормализацию до BCNF, составление DDL-скриптов, планирование индексов и наиболее востребованных запросов. Для управления процессом разработки составлен план-график (диаграмма Ганта) и организован рабочий Git-репозиторий на платформе GitFlic, обеспечивающий контроль версий и прозрачность выполнения задач. В результате можно сделать следующие выводы (табл. 12):
Таблица 12
Выводы по разделу 2
РЕАЛИЗАЦИЯ ПРОТОТИПА ВЕБ-СЕРВИСА «ТЕХЗАДАНИЕ-КОНСТРУКТОР»
Разработка пользовательского интерфейса в концепции
«конструктора документов»
Разработка прототипа интерфейса веб-сервиса
Прототип интерфейса представляет собой детальный план размещения элементов управления на основных страницах веб-сервиса «ТехЗадание-Конструктор». Прототипирование выполнено с использованием графического редактора. Такая визуализация позволяет проектировать пользовательский опыт до начала программирования, оптимизировать расположение элементов и обеспечить интуитивную понятность интерфейса для всех категорий пользователей системы.
Прототип 1: Главная страница (Дашборд) спроектирована как информационный центр системы, предоставляющий пользователю быстрый доступ к ключевым метрикам и последним активностям (рисунок 12).
Рисунок 12 – Прототип главной страницы
На сглавной странице предусмотрены следующие секции и элементы:
шапка страницы содержит заголовок "Панель управления", приветствие пользователя и счетчик уведомлений;
блок статистики – четыре карточки с ключевыми метриками системы (проекты, ТЗ, задачи на проверке, утвержденные документы);
последние проекты – список недавно созданных или измененных проектов с краткой информацией;
последние ТЗ – список технических заданий с указанием их текущего статуса;
быстрые действия – панель с основными кнопками для быстрого доступа к функциям системы.
Прототип 2: Конструктор технического задания – страница конструктора реализует концепцию пошагового создания документа по ГОСТ 34.602-2020.
Эта страница предусматривает наличие секций и элементов:
Шапка редактора с указанием режима работы (создание/редактирование) и используемого шаблона;
Индикатор прогресса визуализирует степень заполнения документа;
Основные поля – название ТЗ, выбор связанного проекта;
Секции документа – структурированные разделы по ГОСТ с обязательными полями;
Боковая панель содержит информацию о шаблоне, инструкции и историю изменений;
Панель действий – кнопки для сохранения черновика или отправки на согласование.
Изображение прототипа приведено на следующей странице (рисунок 13).
Рисунок 13 – Прототип страницы конструктора ТЗ
Прототип 3: Страница согласования (workflow) предназначена для рецензентов и утверждающих лиц (рисунок 14).
Она содержит секции и элементы:
Шапка процесса – информация о проверяемом ТЗ и его текущем статусе
Инструкция рецензенту – рекомендации по проверке документа
Предпросмотр разделов – отображение содержания ТЗ с возможностью комментирования каждого раздела
Общий комментарий – поле для итогового заключения по документу
Панель решения – варианты действий (утвердить, вернуть на доработку, передать дальше);
Боковая панель – статистика проверки, визуализация workflow и критерии оценки.
Рисунок 14 – Прототип страницы согласования ТЗ
Дизайн-макет веб-сервиса в современном корпоративном стиле
Дизайн-макет веб-сервиса «ТехЗадание-Конструктор» разработан в соответствии с современными трендами UI/UX дизайна и корпоративными стандартами Московского университета им. С.Ю. Витте. Цветовая палитра с акцентами для улучшения пользовательского опыта.
Цветовая схема:
основной цвет – синий (#0d6efd), используется для навигации и основных действий;
акцентные цвета:
зеленый (#198754) - для успешных операций (утверждение, завершение);
оранжевый (#fd7e14) - для предупреждений и статусов «в работе»;
красный (#dc3545) - для ошибок и отклонений;
голубой (#0dcaf0) - для информационных блоков и статусов «на проверке»;
фоновые цвета – оттенки серого (#f8f9fa, #e9ecef) для создания контраста и визуального комфорта;
типографика:
основной шрифт: inter или система sans-serif шрифтов для лучшей читаемости;
заголовки: полужирное начертание с иерархией от H1 до H6;
текст: межстрочный интервал 1.6 для комфортного чтения длинных документов;
Ключевые элементы дизайна:
навигационная панель – верхняя панель содержит логотип системы, основные разделы меню (Дашборд, Проекты, ТЗ, Согласование) и блок пользователя с уведомлениями (рисунок 15). Активный раздел выделяется цветом;
Рисунок 15 – Навигационная панель
карточки интерфейса. Все информационные блоки представлены в виде карточек с:
скругленными углами (border-radius: 10px);
тонкой тенью для создания глубины (box-shadow);
Рисунок 16 – Интерфейс страницы конструктора ТЗ
четким разделением на заголовок и содержимое;
индикаторами статуса в виде цветных меток;
конструктор документов (рисунок 16). Интерфейс конструктора реализован по принципу:
каждый раздел ГОСТ представлен отдельной карточкой;
обязательные поля помечены красной звездочкой;
индикатор прогресса в реальном времени;
подсказки и валидация при заполнении;
система workflow. Визуализация процесса согласования выполнена в виде горизонтальной временной шкалы с:
цветовым кодированием этапов;
индикаторами текущего этапа.
Технологическая реализация ключевых модулей веб-сервиса
Веб-сервис «ТехЗадание-Конструктор» был реализован на основе современного технологического стека Python/Django с использованием реляционной базы данных MySQL. Архитектура системы построена по модульному принципу, где каждый функциональный блок отвечает за конкретную бизнес-функцию. Основные модули системы включают: управление шаблонами ГОСТ, конструктор документов, систему согласования, механизм экспорта и систему безопасности. Реализация выполнена с использованием объектно-ориентированного подхода и паттерна MVC (Model-View-Controller), что обеспечивает гибкость и поддерживаемость кода.
Реализация модуля работы с шаблонами ГОСТ 34.602-2020
Модуль работы с шаблонами является фундаментальным компонентом системы, обеспечивающим соответствие выходных документов требованиям ГОСТ 34.602-2020. Реализация основана на модели Template, которая хранит структурированное описание технического задания в формате JSON.
Модель шаблона (apps/specs/models.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/models.py&branch=master):
class Template(models.Model):
"""
Модель шаблона технического задания.
Соответствует таблице 'templates' в БД.
"""
name = models.CharField(
_('Название шаблона'),
max_length=100,
unique=True
)
description = models.CharField(
_('Описание шаблона'),
max_length=255,
blank=True,
null=True
)
structure = models.JSONField(
_('Структура шаблона (JSON)'),
help_text=_('Структура разделов ТЗ по ГОСТ или внутреннему стандарту')
)
based_on_standard = models.CharField(
_('Основан на стандарте'),
max_length=50,
default='ГОСТ 34.602-2020'
)
is_active = models.BooleanField(
_('Активен'),
default=True
)
created_at = models.DateTimeField(
_('Дата создания'),
auto_now_add=True
)
Структура шаблона хранится в формате JSON, что позволяет гибко определять разделы документа, их обязательность и порядок отображения. Типичная структура шаблона включает:
{
"sections": [
{
"id": "1",
"title": "Общие сведения",
"required": true,
"description": "Общая информация о разработке"
},
{
"id": "2",
"title": "Назначение разработки",
"required": true,
"description": "Цели и задачи создания системы"
}
]
}
Административный интерфейс для управления шаблонами предоставляет возможность создавать, редактировать и активировать шаблоны (рисунок 17). Интерфейс включает валидацию JSON-структуры и предпросмотр разделов.
Рисунок 17 – Интерфейс управления шаблонами в административной панели
Пример работы с шаблонами (файл apps/specs/admin.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/admin.py&branch=master):
…
def sections_count(self, obj):
"""
Отображает количество разделов в шаблоне.
"""
sections = obj.get_sections()
return len(sections) if sections else 0
…
Представление выбора шаблона (templates/specs/editor.html, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=templates/specs/editor.html&branch=master) предоставляет пользователю интерактивный интерфейс для выбора подходящего шаблона перед созданием нового ТЗ. Каждый шаблон сопровождается описанием, списком обязательных разделов и визуальным предпросмотром структуры.
Реализация модуля редактора и конструктора ТЗ
Модуль конструктора ТЗ представляет собой интерактивный веб-редактор, позволяющий пользователям заполнять разделы документа в соответствии с выбранным шаблоном. Реализация основана на динамической генерации полей формы на основе структуры шаблона.
Динамическая форма (apps/specs/forms.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/forms.py&branch=master):
class DocumentVersionForm(forms.ModelForm):
"""Форма создания новой версии документа."""
…
def __init__(self, *args, **kwargs):
"""
Инициализация формы.
"""
self.spec = kwargs.pop('spec', None)
self.user = kwargs.pop('user', None)
super().__init__(*args, **kwargs)
if self.spec:
# Добавляем поля для каждого раздела шаблона
template = self.spec.template
sections = template.get_sections()
for section in sections:
section_id = section.get('id')
section_title = section.get('title', section_id)
is_required = section.get('required', False)
# Получаем текущее содержимое раздела
current_content = ''
if self.spec.current_version:
current_content = self.spec.current_version.get_section_content(section_id) or ''
# Создаем поле для раздела
field_name = f'section_{section_id.replace(".", "_")}'
self.fields[field_name] = forms.CharField(
label=section_title,
required=is_required,
initial=current_content,
widget=forms.Textarea(attrs={
'class': 'form-control section-editor',
'rows': 6,
'data-section-id': section_id,
'placeholder': f'Введите содержание раздела "{section_title}"',
}),
help_text=_('Обязательное поле') if is_required else ''
)
…
JavaScript-логика редактора (templates/specs/editor.html) обеспечивает:
подсчет символов в каждом разделе;
автосохранение черновика каждые 30 секунд;
валидацию обязательных полей перед отправкой;
интерактивное сворачивание/разворачивание разделов;
прогресс-бар заполнения документа.
…
// Автосохранение каждые 30 секунд
let autoSaveTimer;
function autoSave() {
if ($('#specForm').length && $('.section-content-input').filter(function() {
return $(this).val().trim().length > 0;
}).length > 0) {
const sectionsData = {};
$('.section-content-input').each(function() {
const sectionId = $(this).data('section-id');
sectionsData[sectionId] = $(this).val();
});
// Здесь можно добавить AJAX запрос для автосохранения
console.log('Автосохранение...', sectionsData);
// Показываем уведомление
showNotification('Черновик автоматически сохранен', 'info');
}
}
…
Интерфейс конструктора (рисунок 16) представляет собой аккордеон-панели с разделами ГОСТ, где каждый раздел содержит:
номер и название раздела;
текстовое поле для ввода содержания;
счетчик символов;
индикатор обязательности заполнения;
подсказки по заполнению.
Версионность документов реализована через модель DocumentVersion, которая сохраняет каждое изменение документа как отдельную версию (apps/specs/forms.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/forms.py&branch=master):
class DocumentVersion(models.Model):
"""
Модель версии документа ТЗ.
Соответствует таблице 'document_versions' в БД.
Атрибуты:
spec: Техническое задание
version_number: Номер версии
content: Содержимое документа в формате JSON
status: Текущий статус согласования
created_by: Автор версии
"""
spec = models.ForeignKey(
TechnicalSpec,
on_delete=models.CASCADE,
verbose_name=_('Техническое задание'),
related_name='versions'
)
version_number = models.PositiveIntegerField(
_('Номер версии'),
default=1
)
content = models.JSONField(
_('Содержимое документа (JSON)'),
help_text=_('Данные всех разделов ТЗ')
)
status = models.ForeignKey(
'workflow.ApprovalStatus',
on_delete=models.PROTECT,
verbose_name=_('Статус согласования'),
related_name='document_versions',
db_column='status_id' # Явно указываем имя столбца в БД
)
created_by = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.PROTECT,
verbose_name=_('Автор версии'),
related_name='created_versions'
)
created_at = models.DateTimeField(
_('Дата создания версии'),
auto_now_add=True
)
comment = models.TextField(
_('Комментарий к изменениям'),
blank=True,
null=True
)
class Meta:
verbose_name = _('Версия документа')
verbose_name_plural = _('Версии документов')
db_table = 'document_versions'
ordering = ['spec', '-version_number']
unique_together = [['spec', 'version_number']]
…
История изменений отображается в виде временной шкалы, показывающей все версии документа, кто и когда их создал, а также статус каждой версии.
Реализация модуля согласования и workflow
Модуль workflow реализует многоэтапный процесс согласования ТЗ в соответствии с требованиями ГОСТ и внутренними регламентами университета. Система поддерживает следующие статусы согласования: «Черновик», «На проверке у руководителя», «На утверждении у зав. кафедрой», «Требует доработки», «Рекомендовано к утверждению», «Утверждено».
Модель статусов (apps/workflow/models.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/workflow/models.py&branch=master):
class ApprovalStatus(models.Model):
"""
Модель статуса согласования ТЗ.
Соответствует таблице 'approval_statuses' в БД.
Атрибуты:
name: Наименование статуса
description: Описание статуса
order_num: Порядковый номер в workflow
is_final: Является ли статус финальным
"""
# Используем константы из settings.py
DRAFT = settings.STATUS_DRAFT
REVIEW = settings.STATUS_REVIEW
APPROVAL = settings.STATUS_APPROVAL
REWORK = settings.STATUS_REWORK
RECOMMENDED = settings.STATUS_RECOMMENDED
APPROVED = settings.STATUS_APPROVED
ARCHIVED = settings.STATUS_ARCHIVED
STATUS_CHOICES = [
(DRAFT, 'Черновик'),
(REVIEW, 'На проверке у руководителя'),
(APPROVAL, 'На согласовании в ДИТ'),
(REWORK, 'Требует доработки'),
(RECOMMENDED, 'Рекомендовано к утверждению'),
(APPROVED, 'Утверждено'),
(ARCHIVED, 'Архивировано'),
]
name = models.CharField(
_('Наименование статуса'),
max_length=50,
unique=True,
choices=STATUS_CHOICES
)
description = models.CharField(
_('Описание статуса'),
max_length=255,
blank=True,
null=True
)
order_num = models.IntegerField(
_('Порядковый номер'),
unique=True,
help_text=_('Для определения последовательности в workflow')
)
is_final = models.BooleanField(
_('Финальный статус'),
default=False,
help_text=_('Пример: для статуса "Утвержден" = True')
)
class Meta:
verbose_name = _('Статус согласования')
verbose_name_plural = _('Статусы согласования')
db_table = 'approval_statuses'
ordering = ['order_num']
…
Форма рецензирования (apps/workflow/forms.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/workflow/forms.py&branch=master) предоставляет интерфейс для проверки ТЗ:
class ReviewForm(forms.Form):
"""
Форма проверки и рецензирования ТЗ.
"""
ACTION_CHOICES = [
('approve', 'Одобрить и перевести на следующий этап'),
('reject', 'Вернуть на доработку'),
('request_changes', 'Запросить изменения'),
('postpone', 'Отложить решение'),
]
action = forms.ChoiceField(
label=_('Решение'),
choices=ACTION_CHOICES,
widget=forms.RadioSelect(attrs={
'class': 'form-check-input',
})
)
comment = forms.CharField(
label=_('Общий комментарий'),
required=False,
widget=forms.Textarea(attrs={
'class': 'form-control',
'placeholder': 'Оставьте общий комментарий по ТЗ',
'rows': 4,
}),
help_text=_('Комментарий будет виден всем участникам процесса согласования')
)
def __init__(self, *args, **kwargs):
"""
Инициализация формы с версией документа.
"""
self.version = kwargs.pop('version', None)
self.user = kwargs.pop('user', None)
super().__init__(*args, **kwargs)
if self.version and self.version.status:
# Настраиваем доступные действия в зависимости от текущего статуса
current_status = self.version.status.name
if current_status == 'Черновик':
self.fields['action'].choices = [
('approve', 'Отправить на проверку руководителю'),
('request_changes', 'Запросить изменения у автора'),
]
elif current_status == 'На проверке у руководителя':
self.fields['action'].choices = [
('approve', 'Одобрить и отправить в ДИТ'),
('reject', 'Вернуть на доработку автору'),
('postpone', 'Отложить решение'),
]
elif current_status == 'На согласовании в ДИТ':
self.fields['action'].choices = [
('approve', 'Одобрить и рекомендовать к утверждению'),
('reject', 'Вернуть на доработку'),
('request_changes', 'Запросить уточнения'),
]
elif current_status == 'Рекомендовано к утверждению':
self.fields['action'].choices = [
('approve', 'Утвердить ТЗ'),
('reject', 'Отклонить утверждение'),
]
def clean(self):
"""
Проверка формы.
"""
cleaned_data = super().clean()
action = cleaned_data.get('action')
comment = cleaned_data.get('comment')
if action == 'reject' and not comment:
raise ValidationError(
_('При возврате на доработку необходимо указать причину.')
)
return cleaned_data
Система комментариев позволяет участникам согласования оставлять замечания к конкретным разделам ТЗ. Каждый комментарий привязывается к разделу и может быть отмечен как исправленный (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/workflow/models.py&branch=master):
class Comment(models.Model):
"""
Модель комментария к разделу ТЗ.
Соответствует таблице 'comments' в БД.
Атрибуты:
version: Версия документа
author: Автор комментария
section_path: Путь к разделу в структуре JSON
content: Текст комментария
is_resolved: Исправлен ли комментарий
"""
version = models.ForeignKey(
'specs.DocumentVersion',
on_delete=models.CASCADE,
verbose_name=_('Версия документа'),
related_name='comments'
)
author = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE,
verbose_name=_('Автор комментария'),
related_name='comments'
)
section_path = models.CharField(
_('Раздел ТЗ'),
max_length=100,
help_text=_('Идентификатор раздела в структуре JSON')
)
content = models.TextField(
_('Текст комментария')
)
is_resolved = models.BooleanField(
_('Исправлено'),
default=False
)
resolved_at = models.DateTimeField(
_('Дата исправления'),
blank=True,
null=True
)
resolved_by = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.SET_NULL,
verbose_name=_('Исправил'),
related_name='resolved_comments',
blank=True,
null=True
)
created_at = models.DateTimeField(
_('Дата создания'),
auto_now_add=True
)
updated_at = models.DateTimeField(
_('Дата обновления'),
auto_now=True
)
class Meta:
verbose_name = _('Комментарий')
verbose_name_plural = _('Комментарии')
db_table = 'comments'
ordering = ['-created_at']
Интерфейс согласования включает:
панель с информацией о ТЗ и текущем статусе;
аккордеон с разделами для рецензирования;
форму для общего комментария;
кнопки действий (одобрить, вернуть на доработку, запросить изменения);
список существующих комментариев;
индикатор прогресса проверки.
Уведомления о новых задачах на согласование отправляются пользователям по электронной почте и отображаются в интерфейсе системы. В навигационной панели отображается счетчик ожидающих проверки ТЗ.
Журнал событий (EventLog) фиксирует все действия пользователей в системе для обеспечения аудита (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/workflow/models.py&branch=master):
class EventLog(models.Model):
"""
Модель журнала событий для аудита действий пользователей.
Соответствует таблице 'event_log' в БД.
Атрибуты:
user: Пользователь, совершивший действие
project: Проект, к которому относится действие
action_type: Тип действия
entity_type: Тип сущности
entity_id: Идентификатор сущности
ip_address: IP-адрес пользователя
"""
# Типы действий
ACTION_CREATE = 'create'
ACTION_UPDATE = 'update'
ACTION_DELETE = 'delete'
ACTION_VIEW = 'view'
ACTION_LOGIN = 'login'
ACTION_LOGOUT = 'logout'
ACTION_APPROVE = 'approve'
ACTION_REJECT = 'reject'
ACTION_COMMENT = 'comment'
ACTION_CHOICES = [
(ACTION_CREATE, 'Создание'),
(ACTION_UPDATE, 'Обновление'),
(ACTION_DELETE, 'Удаление'),
(ACTION_VIEW, 'Просмотр'),
(ACTION_LOGIN, 'Вход в систему'),
(ACTION_LOGOUT, 'Выход из системы'),
(ACTION_APPROVE, 'Утверждение'),
(ACTION_REJECT, 'Отклонение'),
(ACTION_COMMENT, 'Комментирование'),
]
# Типы сущностей
ENTITY_PROJECT = 'Project'
ENTITY_SPEC = 'TechnicalSpec'
ENTITY_VERSION = 'DocumentVersion'
ENTITY_COMMENT = 'Comment'
ENTITY_USER = 'User'
ENTITY_CHOICES = [
(ENTITY_PROJECT, 'Проект'),
(ENTITY_SPEC, 'Техническое задание'),
(ENTITY_VERSION, 'Версия документа'),
(ENTITY_COMMENT, 'Комментарий'),
(ENTITY_USER, 'Пользователь'),
]
objects = EventLogManager()
event_id = models.UUIDField(
_('ID события'),
primary_key=True,
default=uuid.uuid4,
editable=False
)
user = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE,
verbose_name=_('Пользователь'),
related_name='events'
)
project = models.ForeignKey(
'projects.Project',
on_delete=models.SET_NULL,
verbose_name=_('Проект'),
related_name='events',
blank=True,
null=True
)
action_type = models.CharField(
_('Тип действия'),
max_length=50,
choices=ACTION_CHOICES
)
entity_type = models.CharField(
_('Тип сущности'),
max_length=50,
choices=ENTITY_CHOICES,
blank=True,
null=True
)
entity_id = models.CharField(
_('ID сущности'),
max_length=50,
blank=True,
null=True
)
description = models.TextField(
_('Описание действия'),
blank=True,
null=True
)
ip_address = models.GenericIPAddressField(
_('IP-адрес'),
blank=True,
null=True
)
user_agent = models.TextField(
_('User-Agent браузера'),
blank=True,
null=True
)
timestamp = models.DateTimeField(
_('Временная метка'),
auto_now_add=True
)
class Meta:
verbose_name = _('Событие')
verbose_name_plural = _('Журнал событий')
db_table = 'event_log'
ordering = ['-timestamp']
indexes = [
models.Index(fields=['user', 'timestamp']),
models.Index(fields=['project', 'timestamp']),
models.Index(fields=['action_type', 'timestamp']),
]
Реализация модуля экспорта в форматы .docx/.pdf
Модуль экспорта обеспечивает генерацию итогового документа в стандартных форматах, полностью соответствующего требованиям ГОСТ 34.602-2020. Основное внимание уделено экспорту в формат Microsoft Word (.docx), как наиболее востребованному формату деловой документации.
Генерация DOCX (apps/specs/views.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/views.py&branch=master):
@login_required
def export_spec_to_docx(request, pk):
"""
Представление для экспорта ТЗ в формат DOCX.
"""
spec = get_object_or_404(TechnicalSpec, pk=pk)
# Проверка прав доступа
if not (request.user == spec.project.author or
request.user.is_admin or
spec.project.members.filter(user=request.user).exists()):
messages.error(request, 'У вас нет прав для экспорта этого ТЗ.')
return redirect('specs:detail', pk=pk)
# Создание документа
doc = Document()
# Заголовок документа
title = doc.add_heading(spec.title, 0)
title.alignment = WD_ALIGN_PARAGRAPH.CENTER
# Информация о проекте
doc.add_heading('1. Общие сведения', 1)
doc.add_paragraph(f'Проект: {spec.project.title}')
doc.add_paragraph(f'Автор: {spec.author.full_name}')
doc.add_paragraph(f'Дата создания: {spec.created_at.strftime("%d.%m.%Y")}')
doc.add_paragraph(f'Шаблон: {spec.template.name} ({spec.template.based_on_standard})')
doc.add_paragraph(f'Версия документа: {spec.current_version.version_number}')
doc.add_paragraph(f'Статус: {spec.current_version.status.name}')
# Содержание ТЗ
doc.add_heading('2. Содержание технического задания', 1)
if spec.current_version and spec.current_version.content:
sections = spec.current_version.content.get('sections', [])
for section in sections:
# Заголовок раздела
doc.add_heading(section.get('title', ''), 2)
# Содержание раздела
content = section.get('content', '')
if content:
doc.add_paragraph(content)
else:
doc.add_paragraph('(Раздел не заполнен)')
# Сохранение документа
filename = f'ТЗ_{spec.title.replace(" ", "_")}_v{spec.current_version.version_number}.docx'
response = HttpResponse(
content_type='application/vnd.openxmlformats-officedocument.wordprocessingml.document'
)
response['Content-Disposition'] = f'attachment; filename="{filename}"'
doc.save(response)
# Создание записи в журнале событий
from apps.workflow.models import EventLog
EventLog.log_event(
user=request.user,
action_type='export',
entity_type=EventLog.ENTITY_SPEC,
entity_id=spec.id,
project=spec.project,
description=f'Экспорт ТЗ "{spec.title}" в DOCX',
request=request
)
return response
Особенности реализации экспорта:
форматирование по ГОСТ – использование стандартных стилей оформления;
автоматическая нумерация разделов – соответствие структуре ГОСТ 34.602-2020;
обработка пустых разделов – отображение предупреждений о незаполненных обязательных разделах;
включение метаданных – информация о проекте, авторе, версии и статусе документа;
корректное именование файла – автоматическое формирование имени файла на основе названия ТЗ.
Экспорт в PDF (запланированная функциональность) предполагает использование библиотеки ReportLab для генерации PDF-документов с сохранением структуры и форматирования.
Интерфейс экспорта доступен со страницы детального просмотра ТЗ для пользователей с соответствующими правами доступа. Кнопка экспорта активируется только для утвержденных ТЗ или по специальному разрешению администратора.
Реализация системы аутентификации и разграничения прав доступа
Система безопасности веб-сервиса построена на основе кастомной модели пользователя Django с расширенной системой ролей и разрешений. Реализация обеспечивает многоуровневое разграничение прав доступа в соответствии с бизнес-процессом согласования ТЗ.
Кастомная модель пользователя (apps/accounts/models.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/accounts/models.py&branch=master:
class User(AbstractUser):
"""
Расширенная модель пользователя системы.
Соответствует таблице 'users' в БД.
Заменяет стандартную модель User Django.
Атрибуты:
email: Email пользователя (используется как username)
role: Роль пользователя в системе
full_name: Полное имя пользователя
created_at: Дата регистрации
"""
# Убираем стандартные поля username и first_name/last_name
username = None
first_name = None
last_name = None
# Основные поля
email = models.EmailField(
_('Email адрес'),
unique=True,
db_index=True
)
role = models.ForeignKey(
Role,
on_delete=models.PROTECT,
verbose_name=_('Роль'),
related_name='users'
)
full_name = models.CharField(
_('ФИО'),
max_length=150
)
# Дополнительные поля из схемы
login = models.CharField(
_('Логин'),
max_length=50,
unique=True,
db_index=True
)
password_hash = models.CharField(
_('Хэш пароля'),
max_length=255,
editable=False # Управляется через set_password
)
created_at = models.DateTimeField(
_('Дата регистрации'),
auto_now_add=True
)
# Настройки для аутентификации
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = ['full_name', 'login']
objects = UserManager()
class Meta:
verbose_name = _('Пользователь')
verbose_name_plural = _('Пользователи')
db_table = 'users' # Соответствует имени таблицы в БД
def __str__(self):
return f"{self.full_name} ({self.email})"
def save(self, *args, **kwargs):
"""
Переопределяем save для автоматического заполнения login из email.
"""
if not self.login and self.email:
self.login = self.email.split('@')[0]
super().save(*args, **kwargs)
def set_password(self, raw_password):
"""
Сохраняем хэш пароля в поле password_hash.
"""
from django.contrib.auth.hashers import make_password
self.password_hash = make_password(raw_password)
super().set_password(raw_password)
@property
def is_admin(self):
"""Проверяет, является ли пользователь администратором."""
return self.role.name == settings.ROLE_ADMIN if self.role else False
@property
def is_author(self):
"""Проверяет, является ли пользователь автором."""
return self.role.name == settings.ROLE_AUTHOR if self.role else False
@property
def is_reviewer(self):
"""Проверяет, является ли пользователь рецензентом."""
return self.role.name == settings.ROLE_REVIEWER if self.role else False
@property
def is_approver(self):
"""Проверяет, является ли пользователь утверждающим."""
return self.role.name == settings.ROLE_APPROVER if self.role else False
Система ролей включает четыре основных роли:
администратор – полный доступ ко всем функциям системы;
автор – создание и редактирование собственных ТЗ;
рецензент – проверка и комментирование ТЗ;
утверждающий – финальное утверждение документов.
Проверка прав на уровне объектов осуществляется в представлениях (например, в файле представлений для проектов apps\projects\views.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/projects/views.py&branch=master):
class ProjectDetailView(DetailView):
"""
Представление для отображения детальной информации о проекте.
"""
model = Project
template_name = 'projects/detail.html'
context_object_name = 'project'
def get_queryset(self):
"""
Разрешает доступ только автору проекта, участникам и администраторам.
"""
user = self.request.user
if user.is_admin:
return Project.objects.all()
return Project.objects.filter(
Q(author=user) |
Q(members__user=user)
).distinct()
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
project = self.object
recent_events = EventLog.objects.safe_filter(
project_id=project.id # Без str()!
).select_related('user').order_by('-timestamp')[:10]
context.update({
'recent_events': recent_events,
'sidebar_required': True,
'sidebar_section': 'projects',
})
return context
Навигационная адаптация – система автоматически изменяет меню в зависимости от роли пользователя (рисунок 18). Например, раздел меню «Администрирование» отображается только для администраторов.
Аутентификация реализована через стандартную систему Django с кастомной формой входа, использующей email вместо username (apps\accounts\forms.py, https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/accounts/forms.py&branch=master):
class UserLoginForm(AuthenticationForm):
"""
Форма входа пользователя в систему с использованием email.
"""
username = forms.EmailField(label=_('Email адрес'), widget=forms.EmailInput(attrs={'class': 'form-control', 'placeholder': 'Введите ваш email', 'autocomplete': 'email',}))
password = forms.CharField(label=_('Пароль'), widget=forms.PasswordInput(attrs={'class': 'form-control', 'placeholder': 'Введите ваш пароль', 'autocomplete': 'current-password',}))
def clean(self):
"""
Проверка учетных данных пользователя.
"""
email = self.cleaned_data.get('username')
password = self.cleaned_data.get('password')
if email and password:
self.user_cache = authenticate(
self.request,
email=email,
password=password
)
if self.user_cache is None:
raise forms.ValidationError(
_('Неверный email или пароль.'),
code='invalid_login',
)
elif not self.user_cache.is_active:
raise forms.ValidationError(
_('Этот аккаунт неактивен.'),
code='inactive',
)
return self.cleaned_data
Рисунок 18 – Адаптивное меню для разных ролей пользователей
Сессии и безопасность – система использует безопасные сессионные куки, защиту от CSRF-атак, валидацию паролей и другие стандартные механизмы безопасности Django.
Тестовые учетные записи для проверки системы:
администратор: admin@muiv.ru / admin2025;
преподаватель (рецензент): teacher@muiv.ru / teacher1;
студент (автор): student@muiv.ru / student1.
Реализованная система безопасности обеспечивает:
Защиту от несанкционированного доступа;
Разграничение прав в соответствии с бизнес-процессом;
Аудит действий пользователей;
Защиту персональных данных.
Соответствие требованиям информационной безопасности образовательного учреждения
Таким образом, технологическая реализация ключевых модулей веб-сервиса «ТехЗадание-Конструктор» обеспечивает полный функционал для автоматизации процесса формирования, согласования и утверждения технических заданий в соответствии с ГОСТ 34.602-2020. Система демонстрирует высокий уровень интеграции между модулями, удобство использования и соответствие требованиям современной веб-разработки.
Выводы по разделу 3
В ходе раздела 3 была выполнена практическая реализация веб-сервиса «ТехЗадание-Конструктор», что стало завершающим этапом процесса его проектирования и разработки в рамках преддипломной практики. Работа включала создание пользовательского интерфейса, реализацию ключевых функциональных модулей системы и обеспечение её безопасности. Целью данного этапа являлась трансформация аналитических и проектных наработок в работоспособный прототип, демонстрирующий все основные возможности автоматизированного формирования и согласования технических заданий.
Был разработан и визуализирован комплексный пользовательский интерфейс, соответствующий концепции «конструктора документов» и современным стандартам UI/UX. Интерфейс спроектирован с учётом потребностей различных групп пользователей (автора, рецензента, администратора) и обеспечивает интуитивную навигацию по основным функциям системы: от выбора шаблона и заполнения разделов по ГОСТ до отслеживания статуса согласования. Разработаны дизайн-макеты ключевых страниц (дашборд, конструктор ТЗ, панель согласования), выполненные в корпоративном стиле университета.
Технологическая реализация сервиса осуществлена на стеке Python/Django/MySQL, что соответствует ранее выбранной архитектуре и возможностям ИТ-инфраструктуры кафедры.
В результате выполнения работ по реализации прототипа были сформированы и продемонстрированы следующие профессиональные компетенции (табл. 13):
Таблица 13
Выводы по разделу 3
