В настоящее время в любой современной организации независимо от направления ее деятельности внедрение информационных систем значительно упрощает управление деятельностью организации, оптимизирует внешние и внутренние процессы. В условиях цифровой трансформации образования особую актуальность приобретает автоматизация документационного обеспечения, в частности, процессов создания и согласования проектной документации. Однако не каждый сотрудник или студент университета сможет самостоятельно обеспечить соответствие сложной технической документации актуальным государственным стандартам и внутренним регламентам. Поэтому разработка информационной системы для автоматизированного формирования и согласования технических заданий в соответствии с ГОСТ стала актуальной темой исследования. Для удобства использования было принято решение разработать информационную систему в виде веб-сервиса, доступного из браузера, с интуитивно понятным интерфейсом, построенным по принципу конструктора. Такой подход позволит унифицировать процесс, минимизировать ошибки оформления и существенно сократить время цикла подготовки документов.
Актуальность работы обусловлена необходимостью оптимизации документационного сопровождения проектной деятельности в Частном образовательном учреждении высшего образования «Московский университет имени С.Ю. Витте». В рамках подготовки выпускных квалификационных работ студентов IT-направлений регулярно возникает необходимость формирования технических заданий, которые должны соответствовать требованиям ГОСТ 34.602-2020. Существующий ручной процесс формирования ТЗ с использованием разрозненных шаблонов текстовых редакторов, пересылкой файлов по электронной почте и отсутствием контроля версий приводит к снижению производительности, рискам несоблюдения стандартов и потере управляемости. Проведенный в ходе преддипломной практики опрос студентов выпускных курсов показал, что средняя длительность цикла согласования составляет 12,4 дня, документ проходит в среднем 3,8 итерации правок, а только 25% итоговых документов полностью соответствуют структуре ГОСТ. Внедрение специализированного веб-сервиса напрямую соответствует задачам цифровой трансформации университета, повышая эффективность работы преподавателей и студентов.
Объектом исследования выпускной квалификационной работы стал бизнес-процесс «Подготовка, согласование и утверждение технического задания на разработку программного обеспечения» в ЧОУ ВО «Московский университет им. С.Ю. Витте». Данный процесс реализуется в рамках учебной деятельности кафедры информационных систем при подготовке выпускных квалификационных работ студентов и научно-исследовательских проектов. В его основную задачу входит формализация требований к создаваемым информационным системам, обеспечение соответствия документации стандартам и организация взаимодействия между инициатором (студентом), исполнителями (научным руководителем) и утверждающими лицами (заведующим кафедрой). Владельцем процесса выступает кафедра информационных систем, а Департамент информационных технологий выполняет функции технического партнера, обеспечивающего инфраструктурную поддержку системы.
Предметом исследования выпускной квалификационной работы является методология анализа, проектирования и разработки корпоративной информационной системы (веб-сервиса) для автоматизации указанного бизнес-процесса. Исследование охватывает этапы от выявления проблем и сбора требований до проектирования архитектуры, базы данных, пользовательского интерфейса и реализации работоспособного прототипа системы, интегрирующего функции конструктора документов, процесс согласования и управления проектами.
Цель выпускной квалификационной работы – разработать и обосновать архитектуру веб-сервиса для автоматизации процесса формирования и согласования технических заданий в соответствии с ГОСТ 34.602-2020, а также реализовать его функциональный прототип, демонстрирующий решение ключевых проблем существующего процесса в университете.
Основные задачи, необходимые для достижения цели:
провести анализ предметной области для выявления и формализации бизнес-процесса формирования ТЗ, его проблемных зон и ролей участников в организационном контексте ЧОУ ВО «МУ им. С.Ю. Витте»;
сформировать необходимые функциональные и нефункциональные требования к будущей информационной системе на основе анализа потребностей ключевых стейкхолдеров (студентов, научных руководителей, заведующего кафедрой);
проанализировать существующие аналоги, технологии, базы данных и средства разработки для выбора оптимального стека реализации веб-сервиса;
спроектировать логическую и физическую модель данных, архитектуру системы, пользовательские интерфейсы и разработать техническое задание;
разработать веб-сервис «ТехЗадание-Конструктор», реализовав модули конструктора документов, системы согласования, экспорта и безопасности;
провести тестирование прототипа, разработать план его внедрения, интеграции с ИТ-инфраструктурой университета и оценить экономическую целесообразность проекта.
Бакалаврская работа состоит из введения, трех глав, заключения, списка литературы и приложений.
Первая глава посвящена описанию структуры университета и его деятельности, анализу текущего бизнес-процесса формирования ТЗ (AS-IS) с использованием методологий IDEF0, DFD и UML. Выявлены недостатки существующего подхода, проведен анализ рынка программного обеспечения и сформированы детальные требования к разрабатываемой информационной системе, оформленные в виде Технического задания в соответствии с ГОСТ 34.602-2020.
Вторая глава посвящена процессу проектирования архитектуры системы, логической и физической модели базы данных, а также непосредственной разработке веб-сервиса: реализации backend-логики на фреймворке Django, frontend-интерфейсов с использованием Bootstrap 5 и интеграции всех модулей, включая конструктор документов, систему согласования (workflow), модуль контекстных комментариев и экспорт в формат .docx.
В третьей главе описаны вопросы тестирования разработанного программного обеспечения, включая функциональное тестирование методом «черного ящика», смоук-тестирование, тестирование интерфейса и удобства использования, а также автоматизированное модульное тестирование. Составлены планы инсталляции (по методологии сине-зеленого деплоя), интеграции с существующей ИТ-инфраструктурой университета (включая почтовый сервер для уведомлений) и технической поддержки. Разработаны руководства для пользователей и администратора системы.
Ссылка на Git-репозиторий с исходным программным кодом: https://gitflic.ru/project/borovskiy/auto_tech_spec
Ссылка на хостинг с размещенным веб-ресурсом: http://borovsag.beget.tech
Учетные данные для тестирования системы:
администратор: логин – admin@muiv.ru, пароль – admin2025;
руководитель (научный руководитель, преподаватель): логин – teacher@muiv.ru, пароль – teacher1;
студент (исполнитель): логин – student@muiv.ru, пароль – student1.
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
Анализ подразделения Департамент информационных технологий ЧОУ ВО «Московский университет им. С.Ю. Витте»
Дерево бизнес-направлений организации
Московский университет имени С.Ю. Витте, как многопрофильное образовательное учреждение, реализует свою деятельность через несколько ключевых бизнес-направлений, сфокусированных на различных аспектах предоставления образовательных услуг и обеспечения функционирования организации. Дерево бизнес-направлений организации представлено на Рисунке 1.1.
Рисунок 1.1 – Дерево бизнес-направлений ЧОУ ВО «Московский университет им. С.Ю. Витте»
Ключевые направления деятельности:
основная образовательная деятельность. Ядро бизнеса университета, включающее реализацию программ бакалавриата, магистратуры, среднего профессионального образования и дополнительного образования;
научно-исследовательская деятельность. Направление, обеспечивающее развитие научного потенциала, включающее выполнение научно-исследовательских работ, подготовку диссертаций и выпускных квалификационных работ (ВКР);
проектно-внедренческая деятельность. Деятельность, связанная с реализацией проектов, в том числе внутренних ИТ-разработок, хоздоговорных работ и учебных проектов студентов;
административно-хозяйственная деятельность. Обеспечивающие процессы, необходимые для функционирования организации (кадры, финансы, материально-техническая база);
ИТ-обеспечение деятельности университета. Кросс-функциональное направление, поддерживающее все остальные. Включает эксплуатацию инфраструктуры, разработку информационных систем, техническую поддержку, обеспечение информационной безопасности и автоматизацию бизнес-процессов.
За направление ИТ-обеспечения и, в частности, за задачу автоматизации бизнес-процессов отвечает Департамент информационных технологий (ДИТ). Однако в контексте рассматриваемого процесса формирования технических заданий для выпускных квалификационных работ важно разграничить роли подразделений. Владельцем бизнес-процесса подготовки и согласования ТЗ выступает кафедра информационных систем, так как именно она определяет требования к содержанию и оформлению документации, назначает научных руководителей и организует процесс рецензирования и утверждения в рамках учебной деятельности. Департамент информационных технологий выполняет функции технического партнера, обеспечивая серверную инфраструктуру, информационную безопасность и консультационную поддержку при интеграции разрабатываемого веб-сервиса с существующими системами университета. Такое разделение ответственности позволяет сохранить содержательный контроль за процессом на уровне профильной кафедры, одновременно используя технический потенциал ДИТ для обеспечения надежности и масштабируемости решения.
Сопоставление бизнес-процессов и критических факторов успеха организации
Критические факторы успеха (Critical Success Factors, CSF) – это ограниченное количество областей деятельности, где достижение удовлетворительных результатов гарантирует успешную конкурентоспособную работу организации. Для ЧОУ ВО «МУ им. С.Ю. Витте» как негосударственного вуза можно выделить следующие стратегические CSF:
качество образовательных услуг (CSF1) – поддержание высокого уровня преподавания, актуальности образовательных программ и удовлетворенности студентов;
эффективность управления и операционная эффективность (CSF2) – оптимизация внутренних процессов для снижения издержек, повышения скорости принятия решений и адаптивности;
конкурентоспособность и инновационность (CSF3) – внедрение новых образовательных технологий, развитие цифровой образовательной среды, выполнение актуальных НИР и проектов.;
соответствие регуляторным требованиям (CSF4) – строгое соблюдение законодательства в сфере образования, лицензионных требований, стандартов (ФГОС, ГОСТ) при подготовке документации.
Сопоставление ключевых бизнес-процессов университета с выявленными CSF представлено в Таблице 1.1.
Таблица 1.1 – Матрица влияния бизнес-процессов
на критические факторы успеха МУИВ
Процесс «Формирование технического задания на ИТ-проекты» обладает ключевым влиянием на три из четырех CSF:
CSF2 (Эффективность управления). Качественное ТЗ – основа эффективного управления проектом, позволяет четко определить сроки, бюджет и результат, минимизируя риски;
CSF3 (Конкурентоспособность). Быстрая и качественная подготовка ТЗ для внутренних разработок (включая цифровые сервисы для учебного процесса) напрямую влияет на скорость внедрения инноваций в университете;
CSF4 (Соответствие стандартам). Процесс жестко регламентирован ГОСТ 34.602-2020. Его автоматизация гарантирует соблюдение стандартов оформления и полноты документации.
Процесс формирования ТЗ является кросс-функциональным, затрагивающим учебную, научную и проектную деятельность. Его низкая эффективность в текущем ручном исполнении создает «узкое горлышко» для инициации проектов, снижая операционную эффективность и замедляя инновационное развитие. Поэтому для автоматизации выбран именно бизнес-процесс «Формирования, согласования и утверждения технического задания на разработку программного обеспечения для нужд университета».
Анализ структуры и нормативной документации, регламентов подразделения «Департамент информационных технологий» университета, регулирующих выполнение выбранного
бизнес-процесса
Анализ организационной структуры и нормативной базы является фундаментальным этапом для корректной идентификации всех участников бизнес-процесса, их ролей и установленных регламентов. В рамках рассматриваемого процесса подготовки и согласования технических заданий для выпускных квалификационных работ ключевыми подразделениями выступают кафедра информационных систем как владелец процесса и Департамент информационных технологий (ДИТ) как технический партнер, обеспечивающий инфраструктурную поддержку.
Кафедра информационных систем входит в состав Факультета информационных технологий и подчиняется декану факультета. В соответствии с «Положением о кафедре информационных систем», в компетенцию кафедры входят следующие задачи, релевантные выбранному процессу:
организация и руководство выпускными квалификационными работами студентов, включая определение тематики, назначение научных руководителей и контроль соответствия оформления установленным стандартам;
разработка и актуализация учебно-методических материалов, в том числе шаблонов технических заданий для ВКР и научно-исследовательских работ;
обеспечение содержательного контроля качества проектной документации, разрабатываемой студентами;
взаимодействие с другими подразделениями университета по вопросам учебного процесса и проектной деятельности.
Таким образом, кафедра информационных систем является владельцем бизнес-процесса формирования технических заданий для учебных целей, определяя требования к содержанию и оформлению документов, назначая научных руководителей и организуя процесс рецензирования и утверждения.
Департамент информационных технологий (ДИТ) является структурным подразделением, ответственным за обеспечение ИТ-инфраструктуры университета. В рамках рассматриваемого процесса ДИТ выступает в роли технического партнера, обеспечивающего:
выделение серверных ресурсов для развертывания веб-сервиса;
поддержку сетевой инфраструктуры и информационной безопасности;
консультационную поддержку при интеграции с существующими сервисами университета (например, корпоративной почтовой системой).
Такое разделение ответственности соответствует сложившейся в университете практике, где содержательное наполнение образовательного процесса находится в ведении академических подразделений, а техническое сопровождение – в ведении ДИТ.
Выполнение бизнес-процесса регламентируется следующими документами:
а) Внешние нормативные акты:
ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы». Является основополагающим документом, определяющим состав, содержание и оформление технического задания. Обязателен к применению для формализации требований к создаваемым автоматизированным системам, включая учебные проекты студентов.
б) Внутренние нормативные акты университета:
Устав ЧОУ ВО «МУ им. С.Ю. Витте». Определяет общие принципы деятельности, в рамках которых осуществляется образовательная и проектная работа.
«Положение о кафедре информационных систем». Закрепляет цели, задачи, функции и полномочия кафедры. В частности, в нем зафиксирована ответственность за организацию и руководство выпускными квалификационными работами, что является прямым обоснованием для разработки автоматизированной системы формирования ТЗ для учебных целей.
«Положение о Департаменте информационных технологий». Определяет полномочия ДИТ в части обеспечения ИТ-инфраструктуры, автоматизации процессов и внедрения систем электронного документооборота. ДИТ выступает техническим исполнителем, обеспечивающим среду для развертывания и эксплуатации системы.
«Положение об организации проектной деятельности» (или аналогичный внутренний регламент). Определяет общий порядок инициации, планирования, реализации и закрытия проектов в университете, включая этап подготовки технического задания.
Внутренние инструкции и шаблоны. На практике часто используются локальные шаблоны файлов MS Word для оформления ТЗ, которые могут отставать от актуальной версии ГОСТ или противоречить друг другу, что является одной из выявленных проблем.
Анализ выявил разрыв между формальными требованиями и реальной практикой:
используемые разрозненные шаблоны не всегда актуализированы в соответствии с ГОСТ 34.602-2020;
процесс согласования (маршрут движения, сроки, ответственные) часто определяется ad-hoc, что ведет к задержкам и потере контроля;
отсутствует единый репозиторий для хранения ТЗ, их версий и сопутствующей переписки, что нарушает принципы документооборота, задекларированные в положении о кафедре.
Таким образом, кафедра информационных систем обладает всеми необходимыми полномочиями и мотивацией для совершенствования анализируемого процесса в части содержательного контроля и методического обеспечения, а ДИТ – в части технической реализации. Существующая нормативная база задает высокий стандарт (ГОСТ), но ее практическая реализация неформализована и не автоматизирована. Это создает основу для разработки информационной системы, которая будет не просто инструментом, а формальным цифровым регламентом, обеспечивающим выполнение процесса в строгом соответствии с внутренними и внешними требованиями.
Моделирование бизнес-процесса формирования технического задания на разработку программного обеспечения
Моделирование процесса «КАК ЕСТЬ» (AS-IS)
Для всестороннего анализа текущего состояния был проведен комплексный процессный аудит. Существующий бизнес-процесс был детально документирован с использованием трех взаимодополняющих методологий моделирования, что позволило выявить его структуру, информационные потоки, последовательность действий и распределение ответственности между участниками.
Однако для объективного обоснования необходимости автоматизации недостаточно констатации качественных проблем – требуется их количественная оценка. В связи с отсутствием централизованного учета показателей данного процесса в информационных системах университета, для сбора исходных данных был применен метод структурированного интервью и ретроспективного анализа. Целевую группу опроса составили 12 студентов выпускных курсов, завершивших подготовку ВКР в 2024-2025 учебном году. Анализ предоставленной ими переписки и файлов позволил получить следующие усредненные метрики текущего процесса:
средняя длительность цикла согласования (от первой версии до утверждения) составила 12,4 календарных дней.
документ в среднем проходил 3,8 итерации правок, при этом в 42% случаев возникала путаница с версиями файлов.
около 48% времени автора уходило не на содержание, а на техническое оформление документа.
только 25% итоговых документов полностью соответствовали структуре ГОСТ 34.602-2020.
в 100% случаев отсутствовал структурированный архив истории согласования.
Полученные количественные оценки легли в основу дальнейшего моделирования и позволили четко определить проблемные зоны.
Функциональное моделирование в нотации IDEF0 было использовано для определения границ процесса, его входов, выходов, механизмов и управляющих воздействий. Контекстная диаграмма (A-0), представленная на Рисунке 1.2, определяет процесс «Подготовить и согласовать техническое задание» как единый блок, взаимодействующий с внешней средой.
Входы процесса (Inputs): Идея/Потребность (неформализованная заявка) и Разрозненные требования заказчика являются исходным материалом для процесса.
Выходы (Outputs): Утвержденное техническое задание – целевой продукт, и Архив версий и комментариев – побочный, неструктурированный продукт, возникающий из-за несовершенства процесса. Количественный анализ показывает, что этот «архив» в 100% случаев не пригоден для оперативного восстановления полной истории согласования, а в 75% случаев частично утерян.
Управление (Controls): Процесс регулируется ГОСТ 34.602-2020, однако на практике это управление ослабляется использованием Устаревших локальных шаблонов и Требованиями учебного процесса. Это подтверждается тем фактом, что только 25% финальных документов проходят проверку на соответствие стандарту.
Механизмы (Mechanisms): Исполнителями выступают Инициатор (Студент/Сотрудник), Эксперты и руководители, Утверждающее лицо. Инструментами являются MS Word и Электронная почта.
Рисунок 1.2 – Контекстная диаграмма процесса AS-IS в нотации IDEF0
Для детализации внутренней структуры была построена диаграмма декомпозиции первого уровня (Диаграмма A0), представленная на Рисунке 1.3.
Описание подпроцессов:
A1 «Создать черновик ТЗ в MS Word». Инициатор вручную, на основе разрозненных шаблонов, создает первый вариант документа. На этом этапе около 48% времени тратится на техническое оформление, а не на содержание. На выходе – файл-черновик;
A2 «Согласовать черновик по электронной почте». Начинается итерационный цикл рассылки файла, получения правок и комментариев по почте, ручного внесения изменений и повторной рассылки. Длительность этого этапа в среднем составляет 12,4 дня и включает 3,8 итерации. Процесс непрозрачен, что в 42% случаев приводит к ситуации, когда участники работают с неактуальными версиями файлов. Он порождает множество версий файлов;
Рисунок 1.3 – Диаграмма декомпозиции процесса AS-IS (A0)
A3 «Утвердить финальную версию». После достижения консенсуса финальный файл направляется утверждающему лицу по почте для визирования.
Для анализа информационных потоков, хранилищ данных и их преобразований была построена диаграмма потоков данных (DFD) в нотации Гейна-Сарсона (Рисунок 1.4). DFD наглядно демонстрирует разрозненность и неэффективность информационных каналов.
Рисунок 1.4 – Диаграмма потоков данных (DFD) процесса AS-IS
Описание ключевых элементов DFD:
внешние сущности. Инициатор, Эксперт, Утверждающий – участники процесса;
процессы. Создать черновик, Внести правки, Согласовать, Утвердить – преобразования данных;
хранилища данных. Локальный компьютер инициатора, Почтовые ящики участников – разрозненные, несинхронизированные места хранения информации. Отсутствует централизованное хранилище;
Рисунок 1.5 – Диаграмма активностей (UML) процесса AS-IS
потоки данных. Потоки представляют собой файлы .docx и тексты писем с комментариями, циркулирующие по электронной почте. Это создает риски потери актуальной версии и усложняет отслеживание истории изменений.
Диаграмма активностей в нотации UML для текущего состояния процесса (Рисунок 1.5) наглядно демонстрирует последовательность действий участников во времени и выявляет ключевые проблемные зоны в логике выполнения процесса.
Диаграмма организована в три вертикальные дорожки, соответствующие основным ролям:
Автор/Инициатор – создатель документа, ответственный за его подготовку и согласование;
Рецензент/Руководитель – эксперт, осуществляющий проверку содержания (например, научный руководитель);
Утверждающее лицо – финальный инстанс, принимающий решение об утверждении документа (заведующий кафедрой).
Процесс начинается с начального узла (черный круг) в дорожке Автора и может завершиться в двух конечных узлах (черный круг в кольце) – «ТЗ утверждено» или «Процесс отменен».
Основной поток действий:
Фаза 1. Подготовка черновика (доржка Автора). Процесс инициируется действием «Получить задание/идею». Затем автор выполняет «Поиск подходящего шаблона» – критически важное и часто проблемное действие, так как шаблоны могут быть устаревшими или противоречащими друг другу. После выбора шаблона следует «Заполнение разделов ТЗ в MS Word» – длительная ручная работа по форматированию и содержательному наполнению (соотношение содержание/оформление ~ 52%/48%). Завершается фаза сохранением файла;
Фаза 2. Циклическое согласование (взаимодействие всех дорожек). После создания черновика наступает наиболее проблемный этап. Автор выполняет «Подготовка списка рецензентов» и «Отправка файла по email». Далее поток разделяется (развилка – diamond) на параллельные потоки для каждого рецензента.
Для каждого рецензента выполняется независимый цикл:
рецензент получает письмо и «Скачивает вложение»;
выполняет «Изучение документа»;
принимает решение в узле решения:
если документ требует правок, следует «Подготовка комментариев/правок» и «Отправка ответного письма»;
если документ принят, рецензент «Отправляет подтверждение»
По результатам анализа выявлены проблемные зоны:
Отсутствие синхронизации. Каждый рецензент работает независимо, автор не видит общую картину;
Ручная консолидация. После получения всех ответов автор выполняет «Анализ полученных правок», что может быть крайне сложной задачей при противоречивых правках от разных рецензентов. Затем следует «Внесение правок в документ» и «Создание новой версии файла». В среднем этот цикл повторяется 3,8 раза, что напрямую коррелирует с высокой длительностью процесса в 12,4 дня.
После внесения правок автор оценивает, все ли замечания учтены. Если нет – процесс возвращается к повторной отправке файла, образуя потенциально бесконечный цикл.
Фаза 3: Утверждение. Только после завершения всех циклов согласования документ отправляется утверждающему лицу. Утверждающий, получив письмо, изучает документ и принимает решение:
если утверждает – процесс завершается успешно;
если отклоняет – процесс может вернуться на доработку к автору или быть полностью отменен.
Проблемные моменты, выявленные диаграммой:
точки неопределенности:
нет четких критериев перехода от «согласования» к «утверждению»;
отсутствуют сроки выполнения каждого действия;
нет формальных правил разрешения конфликтных правок от разных рецензентов;
избыточные ручные операции:
многократное скачивание/загрузка файлов;
ручное ведение переписки;
ручное управление версиями файлов;
отсутствие контроля:
невозможно отследить, на каком этапе находится документ у каждого рецензента;
нет уведомлений о просрочках;
нет истории принятых решений.
Для формализации ролей и ответственности участников процесса построена матрица RACI (Таблица 1.2). Матрица сопоставляет функции процесса (подпроцессы с диаграммы A0) с ролями.
Таблица 1.2 – Матрица распределения ответственности RACI
для процесса AS-IS
Легенда: R (Responsible) – Ответственный за выполнение, A (Accountable) – Подотчетный (утверждающий решение), C (Consulted) – Привлекаемый к консультации, I (Informed) – Информируемый о результате.
Анализ матрицы RACI выявил следующие проблемы:
перегрузка Инициатора – он является единственным ответственным (R) за три ключевые функции, включая организацию всего согласования, что неэффективно;
размытая подотчетность (A). За этап согласования подотчетным назначен Научный руководитель, но в реальности он часто не имеет полномочий управлять всем маршрутом;
пассивная роль утверждающего лица – утверждающее лицо появляется только в конце процесса (I, затем R), не участвуя в предварительном контроле, что может приводить к возвратам на доработку с самого высокого уровня.
Проведенный количественный и качественный анализ позволяет не только констатировать низкую эффективность текущего процесса, но и сформулировать измеримые цели для проектируемой автоматизированной системы:
цель 1 (по времени). Сокращение среднего цикла согласования с 12,4 до не более 5 календарных дней (целевое сокращение ~60%). Это достигается за счет исключения задержек, связанных с ручной пересылкой файлов и поиском актуальных версий.
цель 2 (по итерациям). Снижение среднего количества итераций с 3,8 до не более 2 (целевое сокращение ~47%) за счет привязки комментариев к конкретным разделам и единой среды редактирования, исключающей разночтения.
цель 3 (по качеству оформления). Обеспечение 100% соответствия структуры итогового документа требованиям ГОСТ 34.602-2020 за счет использования валидируемых встроенных шаблонов и автоматической генерации финального документа.
цель 4 (по сохранности). Обеспечение полного цифрового архива всех версий и комментариев по каждому проекту с возможностью поиска и восстановления.
Текущий процесс характеризуется высокой степенью ручного труда, информационной разрозненностью (файлы в почте, локальные хранилища), непрозрачностью статусов и длительных циклов согласования, а также отсутствием формального регламента workflow. Ключевые проблемы – это риск потери версий, длительные временные разрывы между итерациями, сложность отслеживания истории и комментариев, зависимость от личной дисциплины участников. Полученные количественные метрики подтверждают эти выводы и служат базой для последующей оценки эффективности внедрения разрабатываемого веб-сервиса.
Моделирование процесса «КАК ДОЛЖНО БЫТЬ» (TO-BE)
На основе комплексного анализа модели AS-IS была проведена оценка степени проблемности процесса по заданной шкале (Таблица 1.3).
Таблица 1.3 – Оценка степени проблемности
бизнес-процесса AS-IS
Таким образом, процесс оценивается как «Плохой» (средний балл 4.6). Требуется кардинальная оптимизация.
Определим цели и ключевые показатели улучшения (KPI):
Цель 1: повысить скорость выполнения процесса. KPI: сократить среднюю длительность цикла «создание – утверждение» на 40%;
Цель 2: гарантировать соответствие результата стандартам. KPI: достичь 100% соответствия оформления выходных документов ГОСТ 34.602-2020;
Цель 3: повысить прозрачность и управляемость. KPI: обеспечить 100% отслеживаемость статуса документа и истории всех действий;
Цель 4: снизить операционные издержки. KPI: сократить трудозатраты участников на рутинные операции на 50%.
Целевая модель процесса построена в той же нотации IDEF0 для обеспечения сопоставимости (Рисунок 1.6). Оптимизация проводилась с применением методов:
устранения временных разрывов;
уменьшения количества ручных выходов;
интеграции процессов в единую цифровую среду и параллелизации, где это возможно.
Ключевые изменения в контексте:
входы: Идея/Потребность формализуется как Заявка на проект в системе;
выходы: Утвержденное ТЗ дополняется Структурированным цифровым архивом, который становится полезным продуктом, а не побочным. Отчеты и аналитика – новый выход для управления;
управление: ГОСТ 34.602-2020 интегрирован непосредственно в систему через шаблоны. Добавляется Цифровой регламент (Workflow), жестко управляющий процессом;
механизмы: Основным инструментом становится Веб-сервис «ТехЗадание-Конструктор». Роли участников остаются прежними, но их взаимодействие кардинально меняется.
Рисунок 1.6 – Контекстная диаграмма процесса TO-BE в нотации IDEF0
Диаграмма декомпозиции TO-BE (A0) представлена на Рисунке 1.7 и отражает принципиально новую логику процесса.
Описание оптимизированных подпроцессов и примененные методы:
A1 «Создать проект и черновик ТЗ в конструкторе». Инициатор работает в едином веб-интерфейсе. Система предоставляет актуальные шаблоны по ГОСТ (метод согласования с требованиями). Данные сразу сохраняются в БД, создается первая версия. Устранен этап самостоятельного поиска и форматирования шаблона;
Рисунок 1.7 – Диаграмма декомпозиции процесса TO-BE (A0)
A2 «Запустить и контролировать процесс согласования». Ключевой оптимизированный блок. Автор не рассылает файлы вручную. Он запускает workflow, и система автоматически назначает задачи рецензентам в их личные кабинеты (метод устранения временных разрывов и ручной информации). Все комментарии оставляются в системе, привязываются к разделам. Статус документа обновляется автоматически. Рецензенты могут работать параллельно (метод параллельного выполнения). Процесс становится полностью прозрачным и управляемым;
A3 «Завершить проект: утвердить и экспортировать». Утверждающий принимает решение в системе. После утверждения система генерирует документ в .docx/.pdf. Весь архив (версии, комментарии, лог действий) хранится централизованно и структурированно (метод уменьшения информационной фрагментарности).
Ожидаемый эффект:
устранение ручных операций – исчезают рассылка писем, ручное слияние правок, управление версиями файлов;
централизация информации. Все данные – в единой БД веб-сервиса;
формализация и ускорение. Четкий маршрут согласования (workflow) с контролем сроков исключает неопределенность и сокращает простои;
контроль качества. Шаблоны гарантируют соответствие ГОСТ, система валидации проверяет обязательные поля.
Диаграмма потоков данных (Data Flow Diagram, DFD) для целевого состояния процесса, построенная в нотации Гейна-Сарсона, представляет собой детализированную модель информационных потоков в рамках веб-сервиса «ТехЗадание-Конструктор» (Рисунок 1.8). В отличие от фрагментированной архитектуры AS-IS, модель TO-BE демонстрирует централизованную, модульную и четко структурированную систему, где все данные и взаимодействия управляются единым комплексом процессов.
Ядром целевой архитектуры является сложный процесс П0 «Веб-сервис ТехЗадание-Конструктор», который был декомпозирован на шесть специализированных подпроцессов, каждый из которых отвечает за определенную бизнес-функцию. Такое разделение обеспечивает принцип единой ответственности (Single Responsibility Principle) и облегчает поддержку системы.
П0.1 «Управление проектами и документами» выступает в роли координатора жизненного цикла проекта. Этот процесс получает от Автора (E1) запрос на создание нового проекта, инициирует его в системе и управляет его метаданными. Он является отправной точкой для любого документа и обеспечивает контекст, в рамках которого существует техническое задание.
Рисунок 1.8 - Диаграмма потоков данных процесса «КАК ДОЛЖНО БЫТЬ»
П0.2 «Конструктор ТЗ» является ключевым инструментом для содержательной работы. Он взаимодействует с процессом П0.1 для получения контекста проекта и с базой данных (Д0) для загрузки актуальных шаблонов, соответствующих ГОСТ 34.602-2020. Все действия Автора по заполнению разделов документа (текстовый ввод, загрузка вложений) проходят через этот процесс, который преобразует их в структурированные данные и сохраняет в виде новой версии документа в Д0. Валидация обязательных полей и проверка формата данных также являются его функциями.
П0.3 «Workflow согласования» представляет собой движок бизнес-процесса, который автоматизирует маршрутизацию, контроль и уведомления. Получив от П0.2 сигнал о готовности черновика, этот процесс обращается к Д0, чтобы определить предустановленный маршрут согласования для данного типа проекта. Затем он автоматически и параллельно создает задачи для Научного руководителя (E2), отправляя им уведомления. П0.3 контролирует сроки выполнения, обрабатывает решения рецензентов («принять», «вернуть») и, при выполнении всех условий, автоматически переводит документ в статус «Готово к утверждению», уведомляя Утверждающее лицо (E4).
П0.4 «Система комментариев» обеспечивает контекстную коммуникацию. Когда рецензенты (E2) или утверждающее лицо (E4) оставляют замечания, они направляются в этот процесс. П0.4 привязывает каждый комментарий к конкретной версии документа и конкретному разделу, сохраняя эту структурированную информацию в Д0. Он также управляет жизненным циклом комментария, отслеживая его статус («новый», «исправлено») и уведомляя Автора (E1) о поступлении новых замечаний.
П0.5 «Генерация отчетов и экспорт» отвечает за преобразование структурированных внутренних данных в формы, пригодные для внешнего использования. По запросу пользователей (E1, E4) или автоматически (по триггеру от П0.3) этот процесс извлекает данные из Д0 и генерирует итоговый документ в форматах .docx или .pdf, гарантированно соответствующий требованиям ГОСТ к оформлению.
П0.6 «Управление пользователями и безопасность» является охранным и административным контуром системы. Все запросы от внешних сущностей и взаимодействия между внутренними процессами проходят через проверку прав доступа, осуществляемую этим модулем. Администратор (E5) использует П0.6 для управления учетными записями, назначения ролей и настройки политик безопасности. Процесс также ведет детальный аудит-лог всех действий, сохраняя его в Д0.
Все шесть процессов взаимодействуют с единым централизованным хранилищем – Д0 «База данных проекта». Это принципиальное отличие от модели AS-IS, где данные были разбросаны по личным почтовым ящикам и локальным дискам. В Д0 хранятся:
структурированные данные: профили пользователей, проекты, версии ТЗ, шаблоны, комментарии, статусы workflow – все в виде записей в реляционных таблицах;
метаданные и отношения: четко определенные связи между сущностями (например, какой комментарий к какой версии какого раздела относится);
история изменений: полный аудит-лог, позволяющий восстановить ход процесса в любой момент.
Такая архитектура обеспечивает целостность данных (ACID-свойства СУБД), согласованность (все участники видят одни и те же актуальные данные) и возможность сложной аналитики.
Диаграмма активностей для целевого состояния процесса (Рисунок 1.9) демонстрирует радикальное упрощение и структуризацию процесса за счет внедрения автоматизированной системы.
Основные отличия от AS-IS:
централизованное управление процессом. Появляется четвертая дорожка - «Система ТЗ-Конструктор», которая берет на себя функции координации, уведомления и контроля сроков. Это принципиальное архитектурное изменение;
четкая последовательность и управляемые ветвления. Все развилки (узлы решения) теперь основаны на формальных правилах, а не на субъективных оценках участников.
Фаза 1. Создание документа (оптимизировано). Действие «Поиск подходящего шаблона» заменяется на «Выбор шаблона из каталога системы», что гарантирует актуальность и соответствие ГОСТ. «Заполнение разделов» происходит в веб-интерфейсе с валидацией обязательных полей. Файлы не создаются до момента экспорта.
Рисунок 1.9 – Диаграмма активностей (UML) процесса TO-BE
Фаза 2. Автоматизированное согласование (кардинальные изменения). Вместо ручной рассылки автор выполняет одно действие: «Запуск workflow согласования». Далее система автоматически:
определяет маршрут согласования на основе типа проекта;
назначает задачи рецензентам в их личные кабинеты;
контролирует сроки выполнения;
уведомляет участников о новых задачах и событиях.
Система может назначать задачи нескольким рецензентам параллельно, что сокращает общее время согласования.
Рецензенты оставляют комментарии непосредственно в системе, привязывая их к конкретным разделам. Это исключает проблему интерпретации разрозненных правок из писем.
Система автоматически переводит документ в статус «Готово к утверждению», когда выполнены все условия:
все обязательные рецензенты вынесли решение;
все критические замечания исправлены;
сроки этапа не нарушены.
Фаза 3. Утверждение с полной информацией. Утверждающий получает документ со всей историей – версиями, комментариями, решениями рецензентов. Решение принимается на основе полной информации.
Методы оптимизации, примененные в TO-BE:
устранение временных разрывов – система немедленно уведомляет участников о новых задачах;
параллельное выполнение – несколько рецензентов могут работать одновременно;
стандартизация форм информации – единый интерфейс для комментариев и решений;
автоматизация рутинных операций – рассылка, контроль сроков, смена статусов.
Перераспределение ответственности в новой модели фиксируется в обновленной матрице RACI (Таблица 1.4), где ответственность за техническую организацию процесса переносится с пользователей на информационную систему.
Таблица 1.4 – Матрица распределения ответственности RACI
для процесса TO-BE
Модель TO-BE представляет собой радикально оптимизированный процесс, где основная нагрузка по координации, контролю и обеспечению целостности данных возлагается на автоматизированную информационную систему. Это позволяет перевести процесс из состояния «Плохо» в состояние «Хорошо» или «Отлично» по всем ключевым показателям.
Анализ рынка программного обеспечения для автоматизации бизнес-процесса подготовки и согласования технических заданий
В рамках исследования возможностей автоматизации выбранного бизнес-процесса был проведен анализ российского и международного рынка программного обеспечения. Целью анализа было выявление существующих готовых решений, их функциональных возможностей, стоимости и применимости в контексте специфических требований ЧОУ ВО «Московский университет им. С.Ю. Витте». Исследование позволило определить, что на рынке присутствует ограниченное количество специализированных систем, в то время как более распространены решения широкого профиля, которые могут быть адаптированы для решения задачи.
На рынке представлено несколько категорий программных продуктов, которые потенциально могут быть использованы для автоматизации подготовки ТЗ:
системы управления требованиями (Requirements Management) и ALM. Мощные инструменты для управления жизненным циклом приложений, включая сбор, документирование и отслеживание требований. Часто являются частью крупных экосистем для разработки ПО;
системы электронного документооборота (СЭД) и ECM. Универсальные платформы для создания, согласования, утверждения и хранения любых типов документов. Могут быть настроены под процесс согласования ТЗ;
конструкторы документов и шаблонов. Специализированные онлайн-сервисы, позволяющие создавать структурированные документы на основе шаблонов, часто с простыми процессами согласования;
системы управления проектами (Project Management). Инструменты, в которых функционал документирования требований и задач может быть использован для фиксации ТЗ, но без глубокой специализации под ГОСТ.
Для детального сравнения были выбраны наиболее релевантные аналоги в указанных категориях (Таблица 1.5).
Таблица 1.5 – Сравнительный анализ программных продуктов
для автоматизации подготовки ТЗ
Продолжение таблицы 1.3
Проведенный анализ показал, что универсальные системы (СЭД, ALM) обладают мощным функционалом workflow, управления версиями и интеграциями, но их ключевым недостатком применительно к задаче является отсутствие «из коробки» специализации под стандарт ГОСТ 34.602-2020. Внедрение таких систем потребует значительных затрат на доработку и настройку – для создания специализированных шаблонов документов, настройки маршрутов согласования, интеграции с генерацией .docx. Для университета это означает высокие первоначальные лицензионные расходы и стоимость услуг внедрения, а также зависимость от вендора или выделенного ИТ-специалиста для поддержки конфигурации.
С другой стороны, найденный узкоспециализированный сервис Flockbird демонстрирует, что существует рыночная ниша для инструментов, заточенных именно под задачу формирования ТЗ по ГОСТ. Его наличие подтверждает актуальность разрабатываемого решения. Однако стоимость лицензирования подобных коммерческих продуктов для образовательного учреждения может быть непрозрачной или неоправданно высокой для внутреннего, ограниченного по масштабу использования.
Таким образом, налицо рыночный пробел: отсутствие доступного, сфокусированного на ГОСТ, легкого во внедрении и адаптируемого под внутренние регламенты конкретной организации решения. Это полностью обосновывает целесообразность собственной разработки веб-сервиса «ТехЗадание-Конструктор». Разрабатываемая система позволит:
точно удовлетворить специфические требования университета (интеграция с учебным процессом, роли студент-преподаватель);
обеспечить 100% соответствие шаблонов актуальному ГОСТ без зависимости от обновлений сторонних продуктов;
контролировать общую стоимость владения и иметь полную свободу для доработки и развития системы силами собственного Департамента ИТ;
создать конкурентное преимущество в виде оптимизированного внутреннего процесса, не прибегая к дорогостоящим коммерческим платформам.
Анализ стейкхолдеров и их требований к разрабатываемой системе
Успешная разработка и внедрение информационной системы зависят от точного понимания потребностей всех заинтересованных сторон (стейкхолдеров). Сбор и системный анализ требований будущих пользователей является критически важным этапом проектирования, так как позволяет перевести абстрактную идею автоматизации в конкретный набор функций, которые система обязана выполнять. В рамках анализа бизнес-процесса формирования технического задания были выявлены четыре ключевые группы стейкхолдеров, каждая из которых обладает уникальными целями и требованиями к будущей системе. Для выявления этих потребностей применялся метод анализа типовых рабочих сценариев с ключевыми участниками процесса.
Инициатор / Автор ТЗ (Студент, Младший сотрудник подразделения). Данная группа является первичным пользователем, создающим документ. Их главная цель – минимизировать усилия на формальное оформление и сфокусироваться на содержательной части работы. Для них критически важны:
наличие интуитивно понятного пошагового конструктора с автоматической загрузкой актуального шаблона по ГОСТ 34.602-2020, структурированного по разделам;
понятный и минималистичный интерфейс, исключающий необходимость разбираться в сложной иерархии согласования;
возможность сохранения черновиков, пошаговые подсказки по заполнению полей и четкие инструкции;
простой и ясный механизм отправки документа на проверку, без необходимости ручного выбора каждого согласующего.
Рецензент / Эксперт (Научный руководитель, преподаватель кафедры). Эта группа отвечает за содержательный контроль и качество документа. Их основная задача – эффективное рецензирование. Ключевые требования:
единый интерфейс («Входящие») со списком всех документов, ожидающих проверки, с указанием сроков и приоритетов;
инструмент для оставления замечаний, привязанных к конкретному абзацу или полю ТЗ, а не к документу в целом – это обеспечивает контекстность обратной связи;
возможность четкого действия – утвердить, отклонить с комментариями, запросить изменения – с автоматическим уведомлением автора и изменением статуса документа;
получение уведомлений о новых версиях документа после правок автора.
Утверждающее лицо (Заведующий кафедрой). Эта группа несет итоговую ответственность за результат и контролирует процесс в целом. Их требования носят управленческий и контрольный характер:
полная видимость истории изменений документа, всех пройденных согласований и оставленных комментариев перед принятием финального решения;
функционал финального утверждения и архивации завершенных документов с возможностью контекстного поиска по всему архиву.
Технический стейкхолдер (Департамент ИТ / Администратор системы). Данная группа обеспечивает эксплуатацию, безопасность и развитие системы. Их требования сфокусированы на технологической стороне:
разграничение прав доступа (RBAC), шифрование данных, защита от веб-угроз (XSS, CSRF, SQL-инъекции), механизмы резервного копирования;
чистая архитектура (например, MVC), документированный код, использование стандартного стека технологий (Python/Django/MySQL) для упрощения поддержки;
возможность интеграции с существующей ИТ-инфраструктурой университета (корпоративная почта для уведомлений, возможно, каталог пользователей);
журналирование всех значимых действий пользователей (вход, создание/изменение документов, комментарии) с защитой логов от модификации и хранением не менее 1 года.
Требования стейкхолдеров образуют иерархию – от базовой потребности в удобном инструменте создания документа (Автор) через необходимость в эффективном контроле (Рецензент) к потребностям в стратегическом управлении и аналитике (Утверждающий) и технологической надежности (ИТ-отдел). Выявленные потребности были формализованы, структурированы и разделены на категории согласно стандартной практике разработки требований к программному обеспечению.
Функциональные требования определяют, что именно система должна делать. К ним относятся:
регистрация и аутентификация пользователей с разграничением прав по ролям (RBAC) в соответствии с матрицей доступа;
CRUD-операции (создание, чтение, обновление, удаление) для сущностей «Проект» и «Техническое задание»;
работа с библиотекой шаблонов ТЗ, структурированных по разделам ГОСТ 34.602-2020;
реализация workflow (маршрута согласования) с назначением задач, уведомлениями по электронной почте и автоматическим изменением статусов;
система контекстных комментариев, привязанных к конкретным разделам или абзацам документа;
история изменений документа с возможностью просмотра предыдущих версий;
генерация итогового документа в форматах .docx и .pdf;
формирование стандартных отчетов и панель управления с аналитикой для администратора.
Нефункциональные требования описывают, как система должна выполнять свои функции, задавая критерии качества:
интерфейс должен быть интуитивно понятным для неподготовленного пользователя (студента). Оценка – достижение базовой компетенции работы с системой за время не более 15 минут.
система должна обеспечивать сохранность данных и иметь механизм автоматического резервного копирования. Целевое время доступности (uptime) – не менее 99% в рабочее время (пн-пт, 9:00–21:00). Должна обеспечиваться нулевая потеря подтвержденных транзакций (сохранений документа) при сбоях.
время отклика системы на стандартные операции (загрузка страницы, сохранение черновика) не должно превышать 2 секунд для 95% запросов при одновременной работе до 50 пользователей.
комплекс требований безопасности, включающий:
защита учетных записей – хранение паролей только в хешированном виде (алгоритм bcrypt или PBKDF2 с солью); блокировка учетной записи на 15 минут после 5 неудачных попыток входа.
защита веб-приложения – встроенные механизмы Django должны обеспечивать защиту от типовых уязвимостей OWASP Top 10: CSRF-токены, экранирование вывода для защиты от XSS, параметризованные запросы ORM для защиты от SQL-инъекций.
защита персональных данных (152-ФЗ) – получение явного согласия пользователя на обработку персональных данных при регистрации; использование HTTPS (TLS) для всех соединений, требующих аутентификации; разграничение доступа: пользователь имеет доступ только к своим данным и данным проектов, в которых он участвует; возможность удаления учетной записи и всех связанных персональных данных по запросу пользователя (право на забвение).
все значимые действия пользователей (вход в систему, создание/изменение/удаление документов, изменение статусов, добавление комментариев) должны автоматически фиксироваться в журнале событий (event_log) с указанием: кто (user_id), когда (timestamp), какое действие (action_type), над какой сущностью (entity_type, entity_id), IP-адрес. Журнал событий должен быть защищен от модификации и храниться не менее 1 года.
система должна обеспечивать возможность хранения не менее 10 000 проектов с полной историей версий (из расчета средний размер версии ~50 КБ, среднее количество версий на проект – 10, требуемый объем ~5 ГБ без учета индексов и логов).
Для управления разработкой требования были приоритизированы по методу MoSCoW:
Must have (Обязательно). Аутентификация и регистрация, конструктор ТЗ по шаблону ГОСТ, процесс согласования с контекстными комментариями, экспорт в .docx/.pdf, базовое разграничение прав (студент, руководитель, администратор), журналирование событий.
Should have (Желательно). Панель администратора с отчетами и аналитикой, уведомления по электронной почте, расширенная история изменений с возможностью сравнения версий, настройка маршрутов согласования.
Could have (Возможно). Интеграция с ЭИОС университета (каталог пользователей), мобильная адаптация интерфейса, API для внешних систем.
Won't have (Не сейчас). Встроенный мессенджер для чата, сложные аналитические дашборды с прогнозированием, полнотекстовый поиск по архиву.
В соответствии с принципами инженерии требований, каждое нефункциональное требование должно сопровождаться конкретной метрикой и методом его проверки. Для разрабатываемого веб-сервиса определены следующие верифицируемые показатели качества (Таблица 1.6).
Таблица 1.6 – Метрики качества
и методы верификации требований
Продолжение таблицы 1.3
Разрабатываемая система «ТехЗадание-Конструктор» должна быть сбалансированным решением, которое через свой функционал (конструктор, система комментариев, workflow, дашборд администратора) последовательно удовлетворяет каждую из групп стейкхолдеров, переводя их индивидуальные цели в общий результат – быстрый, качественный и управляемый процесс подготовки технических заданий. Проведенный сбор и анализ требований позволил перейти от общего понимания проблемы «нужно автоматизировать» к четкому и измеримому техническому заданию на проектирование системы, которое фокусируется на решении конкретных задач реальных пользователей, обеспечивая практическую ценность и внедряемость будущего веб-сервиса.
Выбор средств разработки
Выбор технологического стека для разработки веб-сервиса «ТехЗадание-Конструктор» осуществлялся на основе комплексного анализа, включавшего оценку существующей ИТ-инфраструктуры ЧОУ ВО «МУ им. С.Ю. Витте», соответствия функциональным и нефункциональным требованиям, а также критериев производительности, безопасности, сопровождаемости и доступности навыков разработки.
Для объективного выбора технологической платформы был проведен сравнительный анализ трех наиболее релевантных вариантов, способных обеспечить реализацию требуемого функционала в рамках образовательного учреждения. Критерии сравнения выбраны исходя из требований к системе, характеристик ИТ-инфраструктуры кафедры и потенциальных потребностей интеграции.
Исследование материально-технической базы кафедры информационных систем, проведенное в ходе преддипломной практики, выявило наличие согласованного и релевантного стека ПО, что создает благоприятную среду для разработки и последующего внедрения:
на учебных серверах и рабочих станциях установлены Apache, PostgreSQL, MariaDB/MySQL, что свидетельствует об опыте администрирования веб-серверов и реляционных СУБД;
в составе стандартного ПО кафедры присутствуют Python, PyCharm Community Edition, Git, VSCodium и системы виртуализации (VirtualBox). Это формирует готовую среду для full-stack разработки;
использование Kaspersky Endpoint Security указывает на выстроенные процессы информационной безопасности.
Данный анализ позволяет сделать вывод о том, что выбор технологий, уже используемых или знакомых в университетской среде, минимизирует затраты на обучение, интеграцию и долгосрочную поддержку системы.
Далее был проведен сравнительный анализ по ключевым компонентам стека с учетом специфики проекта (средняя сложность бизнес-логики, необходимость быстрого прототипирования, строгие требования к безопасности и данным). Сравнение трех кандидатов – Python + Django, Node.js + Express и Java + Spring Boot – представлено в Таблице 1.7.
Таблица 1.7 – Сравнение стеков для разработки системы
На основе проведенного сравнительного анализа для реализации веб-сервиса «ТехЗадание-Конструктор» был выбран стек на базе Python и веб-фреймворка Django. Данное решение продиктовано следующими факторами.
Язык программирования и веб-фреймворк (Backend): Python + Django 4.x - высокоуровневый язык с чистым синтаксисом, огромным сообществом и богатой экосистемой библиотек. Фреймворк Django предоставляет концепцию «батарейки включены» (batteries-included) – готовые решения для типовых задач веб-разработки:
встроенная административная панель автоматически создается на основе моделей данных, что позволяет администратору управлять пользователями, шаблонами ТЗ и справочниками без написания дополнительного кода.
встроенная ORM (Object-Relational Mapping) абстрагирует работу с базой данных MySQL, обеспечивая безопасность (встроенную защиту от SQL-инъекций через параметризованные запросы) и удобство разработки.
готовая система аутентификации и авторизации позволяет быстро реализовать разграничение прав по ролям (администратор, руководитель, автор) в соответствии с матрицей доступа.
встроенные механизмы защиты от типовых веб-уязвимостей: CSRF-токены, экранирование вывода для защиты от XSS, защита кликджекинга.
Выбор Django обеспечивает возможность дальнейшего развития и поддержки системы силами студентов и выпускников кафедры без привлечения внешних специалистов, что критически важно для образовательного учреждения. Python является основным языком программирования, изучаемым студентами направления «Бизнес-информатика» и смежных IT-специальностей.
Выбор MySQL (или MariaDB как альтернативы) обусловлен следующими преимуществами:
реляционная СУБД с открытым исходным кодом полностью удовлетворяет требованиям проекта к целостности данных, поддержке транзакций (ACID) и выполнению сложных запросов.
широко используется в университете, что обеспечивает доступность компетенций для администрирования. Как показал анализ инфраструктуры, на серверах кафедры уже установлены MySQL/MariaDB.
для работы с БД будет использован Django ORM, что минимизирует необходимость написания прямых SQL-запросов и обеспечивает дополнительную защиту.
PostgreSQL, хотя и является более продвинутой open-source СУБД, для задач проекта избыточна. MySQL проще в освоении и управлении, что соответствует кадровому потенциалу подразделения.
Для клиентской части выбраны базовые технологии с использованием фреймворка Bootstrap:
HTML5, CSS3, JavaScript (ES6+) – стандартные технологии, необходимые для реализации интерфейса конструктора. Основная бизнес-логика и динамика (валидация форм, интерфейс комментариев) будет обрабатываться на сервере с использованием Django Templates и минимального AJAX (с использованием нативного JavaScript или jQuery для простых запросов).
Bootstrap 5 – фреймворк для адаптивной верстки, обеспечивающий современный и отзывчивый интерфейс «из коробки» с минимальными усилиями.
шаблонизатор Django – используется для генерации HTML-страниц на сервере, что упрощает разработку и обеспечивает безопасную вставку данных.
современные JS-фреймворки (React, Vue.js) позволяют создавать более интерактивные SPA-приложения, но добавляют сложность в разработку, развертывание и требуют отдельного API. Их использование было признано избыточным для первой версии системы, где приоритетом является надежность и скорость реализации. В будущем Django может выступать в роли бэкенда, отдающего данные в формате JSON через Django REST Framework, а фронтенд может быть реализован на любом современном JavaScript-фреймворке.
Веб-сервер и инфраструктура развертывания:
Nginx – в качестве reverse proxy (перенаправление запросов к серверу приложений) и для раздачи статических файлов (CSS, JS, изображения).
uWSGI или Gunicorn – в качестве WSGI-сервера для запуска Django-приложения.
данная связка является стандартной для Django-проектов, хорошо документирована и проста в настройке.
Система контроля версий и хостинг проекта:
Git – стандарт де-факто, уже установлен и используется на кафедре.
GitFlic – отечественная платформа, рекомендованная для учебных проектов, что обеспечивает соответствие внутренним требованиям и удобство взаимодействия с руководителем.
Дополнительные библиотеки:
python-docx – для генерации документов в формате .docx из шаблонов.
django-crispy-forms – для улучшенного отображения и стилизации форм.
django-auth-ldap – для потенциальной будущей интеграции с корпоративным каталогом Active Directory университета.
django-rest-framework – для создания API, которое может быть использовано для интеграции с ЭИОС «Электронный университет» или другими сервисами.
Обоснование отказа от альтернативных стеков:
˗ Node.js + Express обеспечивает высокую производительность и асинхронность, а также отлично сочетается с современными JavaScript-фреймворками. Однако он не присутствует в стандартном программном обеспечении компьютерных классов кафедры, что потребовало бы дополнительных административных согласований на установку. Кроме того, язык JavaScript (особенно в асинхронной парадигме) менее привычен для студентов, что осложнило бы поддержку системы в будущем.
˗ Java + Spring Boot – промышленный стандарт для крупных корпоративных систем, обеспечивающий наивысшую надежность и масштабируемость. Однако для задач автоматизации процесса формирования ТЗ его использование является избыточным. Высокий порог вхождения, значительный объем шаблонного кода и более высокие требования к ресурсам делают этот стек неоптимальным для университетского проекта, где приоритетом является быстрота разработки и простота поддержки.
Таким образом, выбранный стек представляет собой сбалансированное, надежное и поддерживаемое решение. Он позволяет быстро реализовать требуемый функционал, используя сильные стороны Django для администрирования, безопасности и работы с данными, а также обеспечить легкое развертывание и сопровождение системы в существующей ИТ-инфраструктуре ЧОУ ВО «МУ им. С.Ю. Витте» силами кафедры информационных систем при технической поддержке ДИТ.
Техническое задание на разработку корпоративной информационной системы
Техническое задание на разрабатываемое ПО представлено в Приложении 1.
Выводы по разделу 1
В ходе выполнения первого раздела был проведен комплексный анализ предметной области, заложивший фундамент для проектирования корпоративной информационной системы. На основе изучения организационной структуры ЧОУ ВО «МУ им. С.Ю. Витте» было определено ответственное подразделение – кафедра информационных систем – и выявлена стратегическая значимость процесса формирования технических заданий для ключевых факторов успеха университета. Детальное моделирование процесса в состоянии «КАК ЕСТЬ» (AS-IS) с использованием нотаций IDEF0, DFD и BPMN позволило объективно оценить его высокую степень проблемности и формализовать ключевые недостатки: ручной труд, информационную разрозненность и непрозрачность согласования. На основе анализа стейкхолдеров были сформулированы сбалансированные требования к системе, а исследование рынка ПО и внутренней ИТ-инфраструктуры обосновало выбор оптимального технологического стека и целесообразность собственной разработки. Итогом аналитической работы стало создание Технического задания, полностью соответствующего ГОСТ 34.602-2020, которое формально закрепляет цели, требования и план создания веб-сервиса «ТехЗадание-Конструктор» и служит основным документом для перехода к этапу проектирования и разработки.
ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ПРОЕКТА
Структурирование требований к разрабатываемой системе
На этапе проектирования ключевым шагом является формализация и структурирование выявленных ранее требований. Это позволяет перейти от текстового описания потребностей стейкхолдеров к конкретным архитектурным и проектно-конструкторским решениям. Для всестороннего описания системы с разных точек зрения были использованы стандартные нотации UML.
Логическое моделирование данных
Диаграмма вариантов использования (Рисунок 2.1) описывает систему с точки зрения внешнего взаимодействия, определяя границы системы и ключевые сценарии использования (варианты использования), доступные каждому актору. Диаграмма наглядно демонстрирует разграничение функциональных возможностей по ролям пользователей.
Акторы и их цели:
автор (Студент/Сотрудник). Основная цель – создать документ и пройти с ним согласование. Его варианты использования включают регистрацию/аутентификацию, управление проектами, создание и редактирование ТЗ в конструкторе, запуск workflow согласования, просмотр комментариев и экспорт утвержденного документа;
рецензент (Руководитель/Эксперт). Цель – эффективная проверка документов. Его функции сосредоточены на управлении задачами («входящими»), рецензировании ТЗ с оставлением контекстных комментариев и принятии решений по документу (принять, вернуть на доработку);
утверждающее лицо. Цель – финальное утверждение документа. Помимо аутентификации, его ключевой вариант использования – утверждение ТЗ на основе полной истории согласований;
администратор системы. Цель – обеспечить работоспособность и конфигурацию системы. В его зоне ответственности находится управление пользователями и ролями, управление библиотекой шаблонов ГОСТ, настройка маршрутов workflow и просмотр системной аналитики.
Рисунок 2.1 – Диаграмма вариантов использования (Use Case Diagram)
веб-сервиса «ТехЗадание-Конструктор»
Диаграмма показывает, что такие функции, как «Просмотреть ТЗ» и «Экспортировать ТЗ», доступны нескольким ролям, но с разным контекстом. Отношение «включить» (<<include>>) указывает, что вариант использования «Запустить workflow согласования» обязательно включает в себя проверку готовности документа.
Диаграмма последовательности (Рисунок 2.2) детализирует один из наиболее критичных сценариев – согласование технического задания. Она показывает временную последовательность взаимодействия объектов (акторов и компонентов системы) в рамках этого сценария.
Описание потока взаимодействия:
инициация – автор через пользовательский интерфейс (UI) отправляет запрос на запуск согласования;
обработка запроса – контроллер SpecController принимает запрос, проверяет права и текущий статус документа;
логика Workflow – контроллер делегирует выполнение бизнес-логики сервисному слою – WorkflowService. Этот сервис определяет необходимый маршрут на основе типа проекта, извлекает из базы данных список назначенных рецензентов;
создание задач и уведомлений – для каждого рецензента WorkflowService создает в БД запись о новой задаче. Параллельно запускается NotificationService, который отправляет электронные письма с уведомлениями рецензентам;
действия рецензента – рецензент входит в систему, видит новую задачу в своем интерфейсе. При открытии документа SpecController и DocumentService загружают актуальную версию и историю комментариев;
принятие решения – рецензент оставляет комментарии (через CommentService) и принимает решение. Его действие (например, «Вернуть на доработку») обрабатывается WorkflowService, который обновляет статус документа, а NotificationService уведомляет Автора;
Рисунок 2.2 – Диаграмма последовательности сценария «Согласование ТЗ»
цикличность – диаграмма иллюстрирует потенциальный цикл (loop) «Доработка-Согласование», который продолжается, пока не будут выполнены все условия для перехода в статус «Готово к утверждению».
Для структурирования функциональных требований и представления иерархии возможностей системы была построена диаграмма декомпозиции функций (Рисунок 2.3). Она разбивает глобальную задачу «Автоматизация формирования и согласования ТЗ» на управляемые модули и подфункции.
Рисунок 2.3 – Дерево функций веб-сервиса «ТехЗадание-Конструктор»
Уровни декомпозиции:
уровень 0 (Корневая функция) «Обеспечить автоматизированное формирование и согласование ТЗ»;
уровень 1 (Основные подсистемы). Выделены четыре ключевые подсистемы: Управление пользователями и безопасность, Управление проектами и ТЗ, Организация workflow согласования и Формирование отчетов и экспорт;
уровень 2 (Функциональные модули). Каждая подсистема детализирована. Например, подсистема «Управление проектами и ТЗ» включает модули управления проектами, управления шаблонами ГОСТ и конструктора документов;
Диаграмма функций служит основой для проектирования модульной архитектуры системы и распределения задач в плане разработки.
Конструирование модели данных
Инфологическое проектирование базы данных началось с построения ER-диаграммы (Рисунок 2.4), которая отображает ключевые сущности предметной области и связи между ними без привязки к конкретной СУБД.
Описание ключевых сущностей:
Пользователь (User) – сотрудник или студент университета, работающий в системе. Является центральной сущностью, участвующей во всех процессах.
Проект (Project) – инициируемая работа (ВКР, НИР), для которой создается ТЗ. Один проект связан с одним основным ТЗ.
Техническое задание (TechnicalSpec) – основной документ, создаваемый в системе. Сущность хранит актуальную версию и метаданные документа.
Версия документа (DocumentVersion) – конкретное состояние ТЗ на определенный момент времени. Позволяет хранить полную историю изменений.
Комментарий (Comment) – замечание или правка, оставленная участником согласования к конкретному разделу ТЗ.
Рисунок 2.4 – ER-диаграмма (концептуальная модель данных)
Шаблон (Template) – формализованная структура ТЗ по ГОСТ 34.602-2020, на основе которой создаются новые документы.
Дополнительные сущности:
Роль (Role) – определяет права доступа в системе (администратор, автор, рецензент, утверждающий, наблюдатель, исполнитель, контроль качества).
Статус согласования (ApprovalStatus) – этап workflow, в котором находится документ (черновик, на проверке, на согласовании, требует доработки, рекомендовано, утверждено, архив, ожидание финансового отдела, юридическая проверка, отклонено).
Журнал событий (EventLog) – фиксация всех значимых действий пользователей в системе.
Участник проекта (ProjectMember) – ассоциативная сущность, связывающая пользователей с проектами и определяющая их роль в конкретном проекте.
Задача на согласование (ReviewTask) – сущность для управления задачами, назначенными на рецензентов.
Сообщение обратной связи (FeedbackMessage) – сущность для хранения сообщений, отправленных через форму обратной связи.
Отчет (Report) – сущность для хранения сгенерированных аналитических отчетов.
Связи «многие-ко-многим», такие как участие пользователей в проектах (Project Members), разрешены через ассоциативные сущности.
Диаграмма классов UML (Рисунок 2.5) является логическим продолжением ER-модели и детализирует структуру данных, добавляя атрибуты, методы и типы данных, характерные для объектно-ориентированной реализации в Django.
Модель включает 13 прикладных таблиц, которые можно разделить на три категории: справочные таблицы, основные бизнес-таблицы и таблицы аудита.
Для каждой таблицы на диаграмме определен полный набор атрибутов с указанием их типов данных, соответствующих СУБД MySQL. Например, таблица document_versions содержит атрибуты version_number (номер версии документа типа INT UNSIGNED), content (содержимое документа в формате JSON) и created_at (дата создания версии с точностью до микросекунд). Таблица templates хранит структуру шаблона в JSON-поле structure, что позволяет гибко определять разделы технического задания без изменения схемы базы данных.
Рисунок 2.5 – Диаграмма классов (логическая модель данных)
Связи между таблицами детализированы с указанием кратности. Например, связь между таблицами technical_specs и document_versions имеет кратность «один ко многим» (1 : 0..*), что означает: одно техническое задание может иметь ноль или несколько версий, а каждая версия принадлежит ровно одному техническому заданию. Связь между technical_specs и projects является связью «один к одному» (1 : 1), так как каждый проект содержит ровно одно техническое задание. Связь между users и projects через промежуточную таблицу project_members реализует отношение «многие ко многим» (разрешенное через ассоциативную сущность), где один пользователь может участвовать в нескольких проектах, а в одном проекте может участвовать несколько пользователей.
Внешние ключи (FOREIGN KEY) обеспечивают ссылочную целостность данных. Например, атрибут role_id в таблице users ссылается на первичный ключ id таблицы roles, гарантируя, что каждый пользователь имеет корректно заданную роль. Атрибут project_id в таблице technical_specs ссылается на id таблицы projects с ограничением ON DELETE CASCADE, что означает автоматическое удаление технического задания при удалении соответствующего проекта. Атрибут current_version_id в таблице technical_specs ссылается на id таблицы document_versions с ограничением ON DELETE SET NULL, позволяя сохранить техническое задание даже при удалении его текущей версии (например, при откате к предыдущей версии).
Таблицы аудита (event_log, review_tasks, feedback_messages, dashboard_report) предназначены для обеспечения прозрачности процессов, контроля действий пользователей и формирования аналитики. Таблица event_log использует в качестве первичного ключа event_id типа CHAR(36) для хранения UUID, что обеспечивает глобальную уникальность идентификаторов событий. Таблица review_tasks связывает технические задания с пользователями-рецензентами и содержит атрибуты status (статус выполнения задачи), decision (принятое решение) и due_date (срок выполнения). Таблица feedback_messages хранит сообщения, отправленные через форму обратной связи, включая метаданные (IP-адрес, User-Agent) для возможности анализа источников обращений.
Для формализации жизненного цикла документа и процесса согласования была разработана диаграмма состояний (Рисунок 2.6). Она описывает, какие статусы (состояния) может иметь сущность TechnicalSpecification / DocumentVersion, и какие события вызывают переходы между этими статусами.
Описание состояний и переходов:
начальное состояние – черновик (Draft). Документ создан и редактируется автором;
событие-триггер – автор запускает согласование. Система проверяет заполненность обязательных полей и переводит документ в состояние «На проверке у руководителя»;
действия в состоянии – в этом состоянии система назначает задачу рецензенту и отправляет уведомление;
альтернативные переходы – из состояния «На проверке» возможны три перехода в зависимости от решения рецензента:
руководитель вернул на доработку -> состояние «Требует доработки». Документ возвращается автору;
руководитель одобрил -> состояние «На утверждении у заведующего кафедрой». Задача назначается следующему рецензенту в цепочке (workflow);
руководитель отклонил -> конечное состояние Отклонено. Процесс завершается отрицательно;
параллельные ветви (Fork/Join) – диаграмма может отражать возможность параллельного согласования у нескольких экспертов одного уровня;
Рисунок 2.6 – Диаграмма состояний жизненного цикла ТЗ
финальные состояния – «Утверждено» (успешное завершение) и «Отклонено» (неуспешное завершение). Попасть в состояние «Утверждено» можно только из состояния «Рекомендовано к утверждению» по событию «Утверждающий утвердил документ».
Данная диаграмма является формальной спецификацией для разработки модуля workflow и управления статусами в базе данных.
Разработка программного обеспечения
План разработки ПО
План разработки веб-сервиса «ТехЗадание-Конструктор» составлен на основе технического задания и с учетом сроков прохождения преддипломной практики (01.12.2025 – 28.12.2025). Основной целью плана является структурирование работ, обеспечение пошагового достижения целей и эффективный контроль за ходом реализации проекта.
Разработка разделена на четыре последовательных этапа, в рамках которых поэтапно создаются и интегрируются компоненты системы: от проектирования и настройки среды до тестирования и подготовки к защите. Каждый этап имеет конкретные задачи, планируемые результаты, ответственных исполнителей и контрольные точки. Руководство проектом и приемка результатов осуществляется руководителем практики от университета, в то время как основную исполнительскую роль выполняет студент-разработчик.
Для наглядного представления временных рамок и параллельности работ план визуализирован в виде диаграммы Ганта (рисунок 8).
План реализуется по итеративному принципу. Еженедельно проводится сверка текущего состояния с планом и демонстрация промежуточных результатов руководителю. Все артефакты (код, схемы, документация) размещаются в Git-репозитории, что обеспечивает контроль версий и прозрачность процесса. Критерием успешного завершения каждого этапа является достижение запланированных результатов, подтвержденное руководителем. Финальным контрольным мероприятием является защита отчета по практике с демонстрацией работоспособного прототипа системы.
Рисунок 8 - План разработки веб-сервиса «ТехЗадание-Конструктор»
Frontend-разработка
Разработка пользовательского интерфейса веб-сервиса «ТехЗадание-Конструктор» велась с ориентацией на ключевые принципы юзабилити и удовлетворение потребностей выявленных стейкхолдеров. Основной задачей было создать интуитивно понятный, эффективный и минималистичный интерфейс, который снижает когнитивную нагрузку на пользователя и позволяет сосредоточиться на содержательной работе, а не на взаимодействии с системой.
Основополагающим подходом стала концепция «прогрессивного раскрытия сложности». Интерфейс для каждой роли начинается с простого и ясного представления ключевых задач. Например, для автора ТЗ основной экран – это конструктор документа, организованный по принципу пошагового мастера. Для рецензента – единый список «Входящих» задач, отсортированный по приоритету и срокам. Такой подход позволил скрыть от пользователя избыточную функциональность, сосредоточив его внимание на текущем действии.
Визуальная и структурная основа интерфейса была построена с использованием фреймворка Bootstrap 5. Выбор обусловлен его зрелостью, наличием готовых, отзывчивых (responsive) компонентов и простотой кастомизации под корпоративный стиль. Это позволило быстро создать адаптивный каркас, корректно отображающийся на различных устройствах, от настольных компьютеров до планшетов. Цветовая схема и стили были адаптированы в соответствии с бренд-буком университета, что обеспечило визуальную интеграцию системы в цифровую среду организации.
Ключевым элементом интерфейса стал «конструктор документов». Его логика была реализована на основе динамически формируемых форм Django. При выборе шаблона система на лету генерирует форму с полями, соответствующими разделам ГОСТ. Для улучшения пользовательского опыта использовалась клиентская валидация на JavaScript, которая мгновенно уведомляла автора о незаполненных обязательных полях, не дожидаясь отправки данных на сервер. Интерактивность была повышена за счет реализации панелей для разделов документа, что позволило работать с длинным документом, не теряя контекста, и сворачивать уже заполненные разделы.
Особое внимание было уделено интерфейсу системы согласования и комментариев. Чтобы исключить проблему разрозненности обратной связи, характерную для модели AS-IS, был реализован механизм инлайн-комментирования. Рецензент может выделить любой абзац в тексте ТЗ и оставить комментарий, который визуально привязывается к выбранному фрагменту. Все комментарии к документу отображаются на единой панели, где автор может видеть их статус («новый», «исправлено») и помечать как решенные. Этот подход превратил процесс рецензирования из хаотичной переписки по почте в структурированный диалог внутри документа.
Для обеспечения обратной связи и информированности пользователей была внедрена система неблокирующих уведомлений. При любом значимом событии (новая задача на согласование, поступил комментарий, статус документа изменен) в углу экрана появляется краткое сообщение. Это позволяет пользователям не прерывать текущую работу для постоянной проверки обновлений. Состояние интерфейса (например, активные кнопки) динамически меняется в зависимости от статуса документа, что исключает возможность выполнения некорректных действий (например, повторная отправка уже согласуемого ТЗ).
Таким образом, фронтенд-разработка была сфокусирована не на создании изощренных визуальных эффектов, а на проектировании ясного, предсказуемого и эффективного рабочего потока. Каждый элемент интерфейса был спроектирован для решения конкретной проблемы пользователя: конструктор – для упрощения создания документа, панель комментариев – для структурирования обратной связи, дашборд – для обеспечения прозрачности процесса. Такой подход обеспечивает низкий порог входа для новых пользователей и высокую продуктивность при постоянном использовании системы.
Backend-разработка
Backend-часть веб-сервиса «ТехЗадание-Конструктор» была реализована на основе фреймворка Django, который обеспечивает четкое разделение ответственности по паттерну MVT (Model-View-Template) и содержит необходимые компоненты для быстрой разработки безопасного бизнес-приложения.
Структура проекта была организована по принципу «приложений» (apps), каждое из которых отвечает за отдельный функциональный модуль:
accounts – управление пользователями, кастомная модель пользователя, аутентификация и авторизация на основе ролей;
projects – сущности «Проект», управление участниками проекта и их ролями в проекте;
specs – ядро системы: модели TechnicalSpec (ТЗ), Template (шаблоны), DocumentVersion (версии документов); представления для конструктора и экспорта;
workflow – логика согласования: модели ApprovalStatus (статусы), ReviewTask (задачи), Comment (комментарии); сервисы workflow и проверки прав;
dashboard – формирование сводных данных, виджетов и аналитики для главной страницы.
Интерфейс конструктора ТЗ (шаблон editor.html) динамически формируется на основе структуры выбранного шаблона, хранящейся в JSON-формате в поле structure модели Template. При запросе страницы редактора представление TechnicalSpecCreateView (для нового ТЗ) извлекает выбранный шаблон и передает его структуру в контекст шаблона (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/views.py&branch=master):
# apps/specs/views.py
class TechnicalSpecCreateView(CreateView):
"""
Представление для создания нового технического задания.
"""
model = TechnicalSpec
form_class = TechnicalSpecForm
template_name = 'specs/editor.html'
def get_form_kwargs(self):
"""
Передает текущего пользователя в форму.
"""
kwargs = super().get_form_kwargs()
kwargs['user'] = self.request.user
return kwargs
def get_initial(self):
"""
Устанавливает проект, если он передан в параметрах.
"""
initial = super().get_initial()
project_id = self.request.GET.get('project')
if project_id:
try:
project = Project.objects.get(id=project_id, author=self.request.user)
initial['project'] = project
except Project.DoesNotExist:
pass
return initial
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
# Получаем шаблон для предварительного просмотра
template_id = self.request.GET.get('template')
if template_id:
try:
template = Template.objects.get(id=template_id, is_active=True)
context['template'] = template
except Template.DoesNotExist:
context['template'] = Template.objects.filter(is_active=True).first()
else:
context['template'] = Template.objects.filter(is_active=True).first()
context.update({
'sidebar_required': True,
'sidebar_section': 'specs',
})
return context
def form_valid(self, form):
"""
Создает ТЗ и первую версию документа.
"""
from apps.workflow.models import ApprovalStatus
import json
# Сохраняем ТЗ
spec = form.save()
# Создаем первую версию документа
template = form.cleaned_data['template']
sections_data = json.loads(self.request.POST.get('sections_data', '{}'))
# Получаем статус "Черновик"
try:
draft_status = ApprovalStatus.objects.get(code='draft')
except ApprovalStatus.DoesNotExist:
draft_status = ApprovalStatus.objects.filter(
name__icontains='черновик'
).first()
if not draft_status:
messages.error(self.request, 'Системная ошибка: не найден статус "Черновик"')
return self.form_invalid(form)
# Формируем содержимое документа с текстом разделов
document_content = {
'sections': []
}
template_sections = template.get_sections()
for template_section in template_sections:
section_id = template_section.get('id')
section_content = sections_data.get(section_id, '')
document_content['sections'].append({
'id': section_id,
'title': template_section.get('title', ''),
'required': template_section.get('required', False),
'description': template_section.get('description', ''),
'content': section_content, # ← КЛЮЧЕВОЕ ИСПРАВЛЕНИЕ
'fields': template_section.get('fields', [])
})
document_version = DocumentVersion.objects.create(
spec=spec,
version_number=1,
content=document_content, # ← Сохраняем с содержимым
status=draft_status,
created_by=self.request.user,
comment='Первая версия документа'
)
messages.success(self.request, f'ТЗ "{spec.title}" успешно создано.')
# Создание записи в журнале событий
from apps.workflow.models import EventLog
EventLog.log_event(
user=self.request.user,
action_type=EventLog.ACTION_CREATE,
entity_type=EventLog.ENTITY_SPEC,
entity_id=spec.id,
project=spec.project,
description=f'Создано ТЗ "{spec.title}"',
request=self.request
)
return redirect('specs:detail', pk=spec.pk)
Метод template.get_sections() парсит JSON-структуру и возвращает список разделов, которые передаются в контекст шаблона. В шаблоне Django-цикл {% for section in template_sections %} генерирует соответствующие поля ввода.
При отправке формы данные валидируются, а затем метод form_valid() в TechnicalSpecUpdateView собирает данные из полей формы и формирует структурированный JSON-объект с содержимым всех разделов.
Этот JSON сохраняется в поле content новой сущности DocumentVersion, обеспечивая хранение полного состояния ТЗ на момент создания версии.
Логика маршрутизации и управления статусами реализована в сервисном слое. При запуске согласования вызывается метод, который создает задачи для рецензентов и меняет статус документа:
# apps/specs/views.py
def start_review(self, request, *args, **kwargs):
"""
Запускает процесс согласования технического задания.
Создает задачи для рецензентов и меняет статус документа.
"""
self.object = self.get_object()
# Проверяем, что текущий пользователь - автор
if self.object.project.author != request.user:
messages.error(request, "Только автор проекта может запустить согласование.")
return redirect('specs:detail', pk=self.object.pk)
# Проверяем, что ТЗ в статусе "Черновик"
draft_status = ApprovalStatus.objects.filter(code='draft').first()
if not draft_status or self.object.current_version.status != draft_status:
messages.error(request, "Согласование можно запустить только для черновика.")
return redirect('specs:detail', pk=self.object.pk)
# Получаем статус "На проверке"
review_status = ApprovalStatus.objects.filter(code='in_review').first()
if not review_status:
messages.error(request, "Системная ошибка: статус 'На проверке' не найден.")
return redirect('specs:detail', pk=self.object.pk)
try:
# Определяем маршрут согласования (упрощенная логика)
# В реальной системе это может быть сложнее с разными workflow
reviewers = self.get_reviewers_for_spec(self.object)
# Создаем задачи для всех рецензентов
for reviewer in reviewers:
ReviewTask.objects.create(
spec=self.object,
assigned_to=reviewer,
status='pending',
due_date=timezone.now() + timedelta(days=3) # Срок 3 дня
)
# Создаем новую версию документа с обновленным статусом
new_version = DocumentVersion.objects.create(
spec=self.object,
version_number=self.object.get_next_version_number(),
content=self.object.current_version.content,
status=review_status,
created_by=request.user,
comment="Запущен процесс согласования"
)
# Обновляем текущую версию ТЗ
self.object.current_version = new_version
self.object.save()
# Отправляем уведомления (заглушка - нужно реализовать NotificationService)
# self.send_review_notifications(reviewers)
messages.success(request, "Процесс согласования успешно запущен. Задачи назначены рецензентам.")
return redirect('specs:detail', pk=self.object.pk)
except Exception as e:
messages.error(request, f"Ошибка при запуске согласования: {str(e)}")
return redirect('specs:detail', pk=self.object.pk)
Для экспорта в формат Microsoft Word использовалась библиотека python-docx. Функция экспорта извлекает содержимое текущей версии и формирует документ:
# apps/specs/views.py
@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 = spec.get_safe_filename()
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
Для защиты от подделки имени файла при экспорте в модели TechnicalSpec реализован метод get_safe_filename(), который очищает название от недопустимых символов (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/specs/models.py&branch=master):
# apps/specs/models.py
def get_safe_filename(self):
"""
Возвращает безопасное имя файла для экспорта.
Используется при генерации DOCX/PDF.
"""
# Сначала берем оригинальное название (уже прошедшее валидацию)
base_name = self.title
# Заменяем пробелы и другие безопасные разделители
safe_name = re.sub(r'[\s]+', '_', base_name) # пробелы -> подчеркивания
safe_name = re.sub(r'[^a-zA-Zа-яА-Я0-9_\-\.\(\)]', '', safe_name) # доп. очистка
# Ограничиваем длину (без учета расширения и префикса)
if len(safe_name) > 100:
safe_name = safe_name[:100]
return f'ТЗ_{safe_name}_v{self.current_version.version_number}.docx'
Backend-разработка была сосредоточена на создании надежного, безопасного и поддерживаемого ядра системы. Четкое разделение на приложения, использование сервисного слоя для бизнес-логики, глубокая интеграция механизмов безопасности Django и ориентация на объектную модель предметной области позволили создать систему, которая корректно обрабатывает запросы интерфейса и обеспечивает целостность данных на всех этапах работы с техническим заданием.
Разработка модели доступа к данным
Разработка модели доступа к данным в веб-сервисе «ТехЗадание-Конструктор» была построена на принципах ролевого разграничения доступа (Role-Based Access Control, RBAC) и проверки прав на уровне объектов (Object-Level Permissions). Эта двухуровневая система обеспечивает как общее управление функциональностью для групп пользователей, так и точный контроль над тем, кто имеет доступ к конкретным проектам и документам.
В основе системы лежит кастомная модель пользователя User, расширяющая стандартную модель Django AbstractUser. Ключевым элементом является связь «многие-к-одному» с моделью Role. На этапе начальной настройки системы создаются четыре базовые роли:
администратор. Полный доступ ко всем функциям, включая управление системой.
автор. Основной пользователь, создающий ТЗ. Может управлять своими проектами, создавать и редактировать ТЗ, запускать согласование.
рецензент. Специалист, проверяющий документы. Имеет доступ к интерфейсу проверки, может оставлять комментарии и принимать решения по документам, назначенным ему.
утверждающий. Лицо, принимающее финальное решение. Может просматривать историю согласования и утверждать документы.
Роли реализованы через отдельную таблицу в БД, что позволяет администратору гибко управлять ими. Общие разрешения (например, видимость пункта меню «Администрирование») проверяются с помощью свойств модели пользователя.
Код кастомной модели пользователя (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/accounts/models.py&branch=master):
# apps/accounts/models.py
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
Ролевой модели недостаточно, так как в рамках одной роли пользователи должны иметь доступ только к «своим» данным. Для этого в методы моделей и представлений встроена дополнительная логика проверки.
Пользователь видит только те проекты, где он является автором или участником. Это реализуется через кастомные менеджеры моделей (Model Manager), которые фильтруют QuerySet по умолчанию.
Пример кастомного менеджера для модели Project (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/projects/models.py&branch=master):
# apps/projects/models.py
class ProjectMember(models.Model):
"""
Модель участника проекта (связь многие-ко-многим).
Соответствует таблице 'project_members' в БД.
Атрибуты:
project: Проект
user: Участник проекта
member_role: Роль участника в проекте
"""
# Роли участников в проекте (используем константы из settings.py)
ROLE_REVIEWER = settings.ROLE_REVIEWER
ROLE_APPROVER = settings.ROLE_APPROVER
ROLE_OBSERVER = 'observer'
ROLE_EXECUTOR = 'executor'
ROLE_CHOICES = [
(ROLE_REVIEWER, 'Рецензент'),
(ROLE_APPROVER, 'Утверждающий'),
(ROLE_OBSERVER, 'Наблюдатель'),
(ROLE_EXECUTOR, 'Исполнитель'),
]
project = models.ForeignKey(
Project,
on_delete=models.CASCADE,
verbose_name=_('Проект'),
related_name='members'
)
user = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE,
verbose_name=_('Участник'),
related_name='project_memberships'
)
member_role = models.CharField(
_('Роль в проекте'),
max_length=50,
choices=ROLE_CHOICES
)
joined_at = models.DateTimeField(
_('Дата присоединения'),
auto_now_add=True
)
class Meta:
verbose_name = _('Участник проекта')
verbose_name_plural = _('Участники проектов')
db_table = 'project_members'
unique_together = [['project', 'user']] # Составной первичный ключ
def __str__(self):
return f"{self.user.full_name} - {self.get_member_role_display()} в проекте '{self.project.title}'"
Для обеспечения безопасности и предотвращения несанкционированного доступа к объектам были разработаны специализированные миксины, расположенные в apps/core/mixins.py (https://gitflic.ru/project/borovskiy/auto_tech_spec/blob?file=apps/core/mixins.py&branch=master):
AuthorRequiredMixin – проверяет, является ли текущий пользователь автором запрашиваемого объекта. Используется в представлениях, где только автор может выполнять действие (например, редактирование проекта). Миксин анализирует наличие атрибута author у объекта или, если объект связан с проектом, проверяет авторство через связанный проект. Администраторы автоматически получают доступ.
MemberRequiredMixin – проверяет, является ли пользователь участником проекта (автором или добавленным участником). Этот миксин критически важен для представлений, отображающих детальную информацию о проекте, так как даже если пользователь знает ID проекта, он не получит доступ, если не является его участником.
CanEditSpecMixin – специализированный миксин для проверки возможности редактирования технического задания. Помимо проверки авторства, он также проверяет статус документа: редактирование разрешено только для версий в статусе «Черновик». Это предотвращает случайные или злонамеренные изменения уже запущенных в согласование или утвержденных документов.
Эти миксины наследуются от UserPassesTestMixin Django и автоматически вызывают метод test_func() при обработке запроса. Если проверка не пройдена, генерируется исключение PermissionDenied (HTTP 403), что гарантирует, что даже при прямой подстановке чужого ID в URL пользователь не получит доступ.
Дополнительно к миксинам, в моделях реализованы методы для проверки прав на уровне объектов. Например, метод spec.can_edit(user) проверяет, может ли пользователь редактировать конкретное ТЗ, учитывая его роль, статус документа и членство в проекте. Эти методы используются как в представлениях для дополнительной валидации, так и в шаблонах для условного отображения элементов интерфейса.
Для обеспечения того, чтобы пользователи видели только доступные им объекты, в менеджерах моделей реализованы кастомные методы фильтрации. Например, Project.objects.for_user(user) возвращает только те проекты, где пользователь является автором или участником. Это предотвращает случайное раскрытие информации о чужих проектах в списках.
Таким образом, в системе реализована трехуровневая защита:
Уровень URL и представлений – миксины проверяют право доступа к конкретному представлению и объекту;
Уровень queryset – автоматическая фильтрация списков объектов, доступных пользователю;
Уровень шаблонов – условное отображение элементов интерфейса (кнопок, ссылок) в зависимости от прав пользователя на конкретный объект и его текущий статус.
Такой подход обеспечивает надежную защиту от несанкционированного доступа и соответствует принципу Defense in Depth (эшелонированная защита). Даже если злоумышленник обойдет один уровень защиты (например, угадав URL), следующие уровни предотвратят неавторизованные действия.
Выводы по главе 2
В ходе второй главы был выполнен комплекс работ по проектированию и разработке веб-сервиса «ТехЗадание-Конструктор». На основе структурированных требований была спроектирована логическая модель данных с использованием UML-диаграмм (вариантов использования, последовательностей, классов, состояний), что позволило детально проработать архитектуру системы и взаимодействие её компонентов. В процессе backend-разработки на Django был реализован функциональный прототип, включающий модули конструктора документов с поддержкой шаблонов ГОСТ, системы workflow для автоматизации согласования, контекстных комментариев и разграничения прав доступа. Frontend-разработка была сфокусирована на создании интуитивного и эффективного пользовательского интерфейса, основанного на принципах прогрессивного раскрытия сложности и построенного с использованием Bootstrap 5. В результате был создан целостный, работоспособный продукт, программная реализация которого полностью соответствует разработанным ранее моделям TO-BE и удовлетворяет заявленным функциональным требованиям, формируя основу для последующего тестирования и внедрения.
ТЕСТИРОВАНИЕ И ИНТЕГРАЦИЯ
Тестирование и отладка разработанного ПО
Тестирование по методу «Черного ящика» (Функциональное тестирование)
Тест план
Идентификатор тест-плана: TP-FUNC-BLACKBOX-01.
Введение: данный тест-план описывает процесс функционального тестирования веб-сервиса «ТехЗадание-Конструктор» методом «черного ящика». Тестирование направлено на проверку корректности работы заявленных функций системы без доступа к внутреннему коду, исключительно через пользовательский интерфейс.
Объект тестирования: веб-сервис «ТехЗадание-Конструктор», версия 1.0 (прототип).
Функции, которые будут протестированы:
аутентификация и авторизация пользователей;
создание и редактирование проектов;
работа конструктора ТЗ: выбор шаблона, заполнение разделов, сохранение черновика;
запуск и прохождение workflow согласования;
система комментирования;
экспорт ТЗ в формате .docx.
Функции, которые не будут протестированы: нагрузочное тестирование, тестирование безопасности на проникновение, детальное тестирование UI/UX.
Тестовые подходы: ручное тестирование на основе тест-кейсов. Валидация поведения системы через веб-браузер.
Критерии прохождения тестирования: все критические (Critical) и значительные (Major) тест-кейсы должны быть пройдены успешно. Блокирующих (Blocker) дефектов быть не должно.
Критерии приостановления и возобновления тестирования: тестирование приостанавливается при обнаружении блокирующего (S1) дефекта, делающего невозможным дальнейшую проверку основных функций. Возобновляется после устранения дефекта.
Результаты тестирования: отчет о тестировании, содержащий матрицу прохождения тест-кейсов и список баг-репортов.
Задачи тестирования: разработка тест-кейсов, выполнение тестов, документирование результатов, составление баг-репортов.
Ресурсы системы: веб-сервер с развернутым приложением, браузер Google Chrome последней версии, тестовые учетные записи (Автор, Рецензент, Администратор).
Обязанности: тестировщик – выполнение тестов и составление отчетов. Разработчик – анализ и исправление выявленных дефектов.
Роли и ответственность: ответственный за тестирование – студент-разработчик. Ответственный за приемку – руководитель практики.
Расписание: 20.12.2025 – 22.12.2025.
Оценка рисков: нестабильность тестового окружения, отсутствие доступа к определенным ролям пользователей для проверки всех сценариев.
Согласования: согласовано руководителем практики.
Тест-кейсы
Тест-кейс TC-FUNC-01 – успешная аутентификация пользователя:
Предусловия: пользователь с email student@muiv.ru и паролем student1 зарегистрирован в системе.
Шаги: открыть страницу входа (/accounts/login/). В поле «Email» ввести student@muiv.ru. В поле «Пароль» ввести student1. Нажать кнопку «Войти».
Ожидаемый результат: происходит редирект на главную страницу (/dashboard/). В правом верхнем углу отображается имя пользователя. Отображается меню, соответствующее роли «Автор».
Тест-кейс TC-FUNC-02 – создание нового проекта и ТЗ:
Предусловия: пользователь авторизован как Автор.
Шаги: перейти в раздел «Проекты» -> «Создать проект». Заполнить поле «Название проекта»: Тестовый проект ВКР. Заполнить поле «Описание»: Описание тестового проекта. Нажать кнопку «Сохранить». В карточке созданного проекта нажать «Создать ТЗ». В модальном окне выбрать шаблон «ГОСТ 34.602-2020 (Базовый)» и нажать «Создать».
Ожидаемый результат: проект сохраняется, пользователь перенаправляется на страницу списка проектов, где видит новую запись. Открывается страница конструктора ТЗ с предзаполненными разделами выбранного шаблона. Заголовок ТЗ по умолчанию совпадает с названием проекта.
Тест-кейс TC-FUNC-03 – запуск процесса согласования и оставление комментария рецензентом:
Предусловия: существует ТЗ в статусе «Черновик», созданное Автором (student@muiv.ru). Пользователь авторизован как Рецензент (teacher@muiv.ru).
Шаги (от лица Автора): открыть ТЗ в конструкторе. Заполнить несколько обязательных разделов. Нажать кнопку «Отправить на согласование».
Шаги (от лица Рецензента): выйти из системы и авторизоваться как teacher@muiv.ru. На главной странице или в разделе «Согласование» увидеть новую задачу. Открыть задачу. В разделе «Назначение разработки» выделить текст и нажать иконку «Добавить комментарий». Ввести текст: «Требуется конкретизировать цель». Нажать кнопку «Сохранить». Нажать кнопку «Вернуть на доработку».
Ожидаемый результат: статус ТЗ меняется на «На проверке у руководителя». Автор видит соответствующее сообщение. В списке задач Рецензента появляется новая запись с названием ТЗ. Комментарий появляется на панели справа, привязанный к выбранному разделу. Статус ТЗ меняется на «Требует доработки». Автор получает уведомление (проверяется в интерфейсе системы) и видит новый комментарий.
Баг-репорты
Баг-репорт BR-FUNC-01 (ID: BR-FUNC-01):
Заголовок: кнопка «Отправить на согласование» активна при незаполненных обязательных полях.
Описание: в конструкторе ТЗ, если не заполнены поля, помеченные как обязательные (например, «Наименование системы»), кнопка «Отправить на согласование» все равно доступна для нажатия. При нажатии система выдает общую ошибку валидации, а не указывает на конкретные незаполненные поля.
Шаги воспроизведения: авторизоваться как Автор. Создать новое ТЗ на основе шаблона ГОСТ. Оставить обязательные поля пустыми. Нажать кнопку «Отправить на согласование».
Фактический результат: происходит POST-запрос, сервер возвращает ошибку 400 Bad Request с JSON, содержащим список ошибок. Пользовательский интерфейс не подсвечивает проблемные поля.
Ожидаемый результат: кнопка должна быть неактивна (задизейблена) до тех пор, пока все обязательные поля не пройдут клиентскую валидацию. Либо при нажатии должна происходить четкая валидация с подсветкой незаполненных полей прямо в интерфейсе конструктора.
Серьезность: S3 – значительная (Major). Функционал работает, но логика некорректна, что ухудшает пользовательский опыт.
Приоритет: средний.
Баг-репорт BR-FUNC-02 (ID: BR-FUNC-02):
Заголовок: при экспорте ТЗ в .docx не переносятся разрывы строк из текстовых полей.
Описание: текст, введенный в многострочные текстовые поля конструктора с переносами строк, в сгенерированном документе Word отображается как сплошной текст, теряя абзацное форматирование.
Шаги воспроизведения: создать ТЗ и в разделе «Назначение разработки» ввести текст с несколькими абзацами (через Enter). Сохранить ТЗ. Нажать кнопку «Экспорт в DOCX». Открыть полученный файл.
Фактический результат: весь текст раздела слит в один абзац.
Ожидаемый результат: структура текста (абзацы, переносы строк), введенная пользователем, должна сохраняться в итоговом документе Word.
Серьезность: S3 – значительная (Major). Функция экспорта работает, но результат не соответствует ожиданиям по качеству форматирования.
Приоритет: средний.
Баг-репорт BR-FUNC-03 (ID: BR-FUNC-03):
Заголовок: отсутствует визуальное отличие прочитанных/ непрочитанных комментариев для автора.
Описание: когда рецензент оставляет комментарий, автор видит его в списке. Однако после прочтения комментарий никак не меняет своего вида. Это может привести к путанице при множественных правках.
Шаги воспроизведения: рецензент оставляет комментарий к ТЗ. Автор заходит в ТЗ и видит комментарий. Автор исправляет текст согласно комментарию.
Фактический результат: комментарий остается подсвеченным как «новый» даже после того, как автор его увидел и отреагировал.
Ожидаемый результат: должна быть возможность пометить комментарий как «прочитанный» или «исправленный». Визуально прочитанные комментарии могут менять цвет или иметь индикатор статуса (например, галочку).
Серьезность: S4 – незначительная (Minor). Не нарушает основную логику, но снижает удобство отслеживания правок.
Приоритет: низкий.
Тестирование по методу «Смоук-тестирование» (Smoke Testing)
Тест план
Идентификатор тест-плана: TP-SMOKE-01.
Введение: смоук-тестирование (дымовое тестирование) проводится для проверки стабильности новой сборки веб-сервиса «ТехЗадание-Конструктор» и подтверждения того, что критически важные для бизнеса функции работают после обновления или развертывания. Цель – быстро выявить блокирующие дефекты, которые делают систему непригодной для дальнейшего, более детального тестирования.
Объект тестирования: веб-сервис «ТехЗадание-Конструктор», версия 1.0, после развертывания на тестовый стенд.
Функции, которые будут протестированы. Минимальный набор ключевых функций, составляющих критический путь пользователя:
доступность веб-сервера и загрузка главной страницы;
функции аутентификации для всех ролей;
создание нового проекта (базовая операция);
создание ТЗ на основе шаблона и сохранение черновика;
запуск процесса согласования (перевод статуса);
доступ к интерфейсу рецензирования для соответствующей роли.
Функции, которые не будут протестированы: углубленное тестирование всех полей конструктора, полный цикл workflow со всеми этапами, экспорт документов, панель администратора, работа с файлами-вложениями.
Тестовые подходы: быстрое, поверхностное ручное тестирование по заранее подготовленному чек-листу. Акцент на проверку «работает/не работает», а не на детальное соответствие требованиям.
Критерии прохождения тестирования: все тесты из смоук-набора должны быть пройдены успешно. Отсутствие блокирующих (S1) и критических (S2) дефектов, препятствующих выполнению основных операций.
Критерии приостановления и возобновления тестирования: тестирование приостанавливается немедленно при обнаружении любого дефекта уровня S1 (Блокирующий) или двух и более дефектов уровня S2 (Критический), делающих невозможным продолжение проверки критического пути. Возобновляется после предоставления разработчиками исправленной сборки.
Результаты тестирования: краткий отчет о смоук-тестировании с бинарным результатом (ПРОШЕЛ/НЕ ПРОШЕЛ) и списком выявленных критических дефектов.
Задачи тестирования: проверка доступности сервиса, выполнение чек-листа смоук-тестов, фиксация результатов.
Ресурсы системы: развернутое приложение на тестовом URL, браузер, тестовые учетные записи для ролей Автор (student@muiv.ru) и Рецензент (teacher@muiv.ru).
Обязанности: тестировщик – выполнение чек-листа. Системный администратор – обеспечение доступности тестового стенда.
Роли и ответственность: ответственный за тестирование – студент-разработчик. Ответственный за развертывание – руководитель практики/сотрудник ДИТ.
Расписание: проводится после каждого успешного развертывания новой версии на тестовый стенд (планово: 23.12.2025).
Оценка рисков: недоступность тестового стенда, некорректные данные в тестовой БД, отсутствие тестовых пользователей необходимых ролей.
Согласования: согласовано руководителем практики.
Тест-кейсы
Тест-кейс TC-SMOKE-01 – доступность системы и аутентификация:
Предусловия: веб-сервис развернут на тестовом сервере. БД содержит тестовых пользователей.
Шаги: открыть в браузере корневой URL тестового стенда (например, http://test-server/). Убедиться, что страница загружается без ошибок HTTP (5xx) и в консоли браузера нет критических JS-ошибок. Перейти по ссылке «Войти» на страницу аутентификации (/accounts/login/). Ввести учетные данные Автора (student@muiv.ru / student1), нажать «Войти». Убедиться в успешном редиректе на главную страницу. Нажать «Выйти». Повторить шаги 4-5 для учетной записи Рецензента (teacher@muiv.ru / teacher1).
Ожидаемый результат: страница загружается, отображается заголовок системы. Происходит успешный вход, отображается имя пользователя и меню, соответствующее его роли.
Тест-кейс TC-SMOKE-02 – создание проекта и базовой операции с ТЗ:
Предусловия: пользователь авторизован как Автор.
Шаги: перейти в раздел «Проекты». Нажать «Создать проект». Заполнить только обязательное поле «Название» (например, Smoke Test Project), нажать «Сохранить». В списке проектов найти созданный и нажать «Создать ТЗ». В модальном окне выбрать первый доступный шаблон, нажать «Создать». На открывшейся странице конструктора убедиться, что загрузилась форма с разделами. Заполнить одно текстовое поле (например, «Наименование системы»). Нажать кнопку «Сохранить черновик». Убедиться, что страница обновилась без ошибок и появилось сообщение об успешном сохранении.
Ожидаемый результат: проект создается, пользователь возвращается к списку проектов. Происходит переход на страницу конструктора. Данные сохраняются, отображается подтверждающее сообщение. При обновлении страницы введенный текст остается.
Тест-кейс TC-SMOKE-03 – запуск согласования и доступ к задаче рецензента:
Предусловия: существует ТЗ в статусе «Черновик», созданное в TC-SMOKE-02.
Шаги (от лица Автора): на странице конструктора ТЗ нажать кнопку «Отправить на согласование». Подтвердить действие в диалоговом окне (если есть). Убедиться, что статус ТЗ на странице изменился (например, на «На проверке»).
Шаги (от лица Рецензента): выйти из системы и авторизоваться как Рецензент (teacher@muiv.ru). На главной странице или в разделе «Согласование» проверить наличие новой задачи с названием созданного ТЗ. Нажать на задачу, чтобы открыть интерфейс рецензирования. Убедиться, что документ загружается, видны его разделы и основные элементы интерфейса (кнопки «Принять», «Вернуть», поле для комментария).
Ожидаемый результат: статус ТЗ визуально обновляется. Задача появляется в списке «Требуют моего внимания». Страница рецензирования загружается корректно, без ошибок.
Баг-репорты
Баг-репорт BR-SMOKE-01 (ID: BR-SMOKE-01):
Заголовок: веб-сервис недоступен после развертывания (ошибка 500).
Описание: после развертывания новой сборки на тестовый стенд корневой URL возвращает ошибку HTTP 500 Internal Server Error. Журнал ошибок сервера указывает на неудачное выполнение миграций БД из-за конфликта схемы.
Шаги воспроизведения: развернуть сборку v1.0 на тестовый сервер. Открыть корневой URL в браузере.
Фактический результат: отображается стандартная страница ошибки Django/сервера с кодом 500.
Ожидаемый результат: должна загружаться главная страница или страница входа в систему.
Серьезность: S1 – блокирующая (Blocker). Система полностью неработоспособна.
Приоритет: высокий. Требует немедленного исправления перед любым другим тестированием.
Баг-репорт BR-SMOKE-02 (ID: BR-SMOKE-02):
Заголовок: авторизация пользователя с ролью «Рецензент» невозможна.
Описание: при попытке входа с учетными данными teacher@muiv.ru система возвращает ошибку «Неверный email или пароль», несмотря на корректность данных. Вход для Автора (student@muiv.ru) при этом работает.
Шаги воспроизведения: открыть страницу входа. Ввести email teacher@muiv.ru, пароль teacher1. Нажать «Войти».
Фактический результат: отображается сообщение об ошибке аутентификации. Вход не выполняется.
Ожидаемый результат: успешный вход и редирект на главную страницу.
Серьезность: S2 – критическая (Critical). Критический путь для одной из ключевых ролей пользователя нарушен, что делает невозможным тестирование процесса согласования.
Приоритет: высокий.
Баг-репорт BR-SMOKE-03 (ID: BR-SMOKE-03):
Заголовок: кнопка «Отправить на согласование» не вызывает никакого действия.
Описание: на странице конструктора ТЗ, находящегося в статусе «Черновик», кнопка «Отправить на согласование» кликабельна, но при нажатии не происходит никакой видимой реакции: нет запроса к серверу, не меняется статус, не выводится сообщение.
Шаги воспроизведения: авторизоваться как Автор. Открыть существующее ТЗ в статусе «Черновик». Нажать кнопку «Отправить на согласование».
Фактический результат: кнопка нажимается, но визуально ничего не происходит. Статус документа не меняется.
Ожидаемый результат: должен отправляться POST-запрос, статус ТЗ должен измениться, должно появиться уведомление об успехе.
Серьезность: S2 – критическая (Critical). Ключевая бизнес-функция (инициация согласования) не работает.
Приоритет: высокий.
Тестирование интерфейса (GUI Testing)
Тест план
Идентификатор тест-плана: TP-GUI-01.
Введение: тестирование графического пользовательского интерфейса (GUI) направлено на проверку соответствия визуальных элементов и их поведения заявленным требованиям. Цель – убедиться, что интерфейс веб-сервиса «ТехЗадание-Конструктор» является корректным, последовательным, удобным и функционирует как ожидается на разных разрешениях экрана и в разных браузерах.
Объект тестирования: пользовательский интерфейс веб-сервиса «ТехЗадание-Конструктор», версия 1.0.
Функции, которые будут протестированы:
внешний вид и компоновка элементов на основных страницах (логин, дашборд, список проектов, конструктор ТЗ, интерфейс рецензирования);
корректность отображения текста, шрифтов, цветов, выравнивания;
работоспособность и логичность всех интерактивных элементов (кнопки, ссылки, поля ввода, выпадающие списки);
валидация полей ввода и отображение сообщений об ошибках;
адаптивность интерфейса (отображение на экранах разного размера);
навигация (работа меню, хлебные крошки, кнопки «Назад»).
Функции, которые не будут протестированы: глубокое тестирование бизнес-логики, производительности бэкенда, безопасности.
Тестовые подходы: ручное визуальное тестирование и проверка взаимодействия. Использование инструментов разработчика браузера для эмуляции различных размеров экрана.
Критерии прохождения тестирования: все критические для пользовательского опыта элементы интерфейса отображаются и функционируют корректно. Отсутствуют визуальные дефекты, делающие интерфейс нечитаемым или неудобным для использования. Все сообщения об ошибках понятны и корректно локализованы.
Критерии приостановления и возобновления тестирования: тестирование приостанавливается при обнаружении дефекта, полностью блокирующего использование ключевой страницы (например, наложение элементов, делающее кнопки недоступными). Возобновляется после предоставления исправления.
Результаты тестирования: отчет о тестировании GUI с приложенными скриншотами выявленных дефектов.
Задачи тестирования: проверка всех страниц и состояний интерфейса, документирование визуальных и функциональных несоответствий.
Ресурсы системы: тестовый стенд приложения, браузеры Google Chrome (основной) и Mozilla Firefox (дополнительно на выборочную проверку), инструменты разработчика браузера.
Обязанности: тестировщик – выполнение проверок и фиксация дефектов.
Роли и ответственность: ответственный за тестирование – студент-разработчик.
Расписание: 22.12.2025 – 23.12.2025.
Оценка рисков: субъективность оценки визуальных дефектов, невозможность проверить все комбинации разрешений и браузеров.
Согласования: согласовано руководителем практики.
Тест-кейсы
Тест-кейс TC-GUI-01 – внешний вид и адаптивность главной страницы (Дашборда):
Предусловия: пользователь авторизован как Автор.
Шаги: перейти на главную страницу (/dashboard/). Проверить корректность отображения всех элементов: заголовок, карточки статистики, списки последних проектов и ТЗ, навигационная панель, футер. Убедиться, что текст во всех элементах читаем, нет обрезанных слов или наложений. С помощью инструментов разработчика браузера эмулировать разрешение планшета (768x1024). Повторить визуальную проверку. Эмулировать разрешение мобильного телефона (375x667). Повторить визуальную проверку, уделив особое внимание навигационному меню (должно сворачиваться в «гамбургер»).
Ожидаемый результат: на всех разрешениях интерфейс отображается без горизонтальной прокрутки. Элементы не накладываются друг на друга. На мобильном разрешении навигация доступна через гамбургер-меню. Текст остается читаемым.
Тест-кейс TC-GUI-02 – поведение и валидация полей в конструкторе ТЗ:
Предусловия: пользователь авторизован как Автор, открыт конструктор нового ТЗ.
Шаги: оставить обязательное текстовое поле пустым. Нажать кнопку «Сохранить черновик». Ввести в числовое поле (если есть, например, «Срок разработки, мес.») текст abc. Нажать «Сохранить черновик». Ввести в поле с ограничением по длине (например, «Краткое наименование») строку, значительно превышающую лимит. Нажать «Сохранить черновик».
Ожидаемый результат: поле должно быть визуально подсвечено (например, красной рамкой). Рядом с полем или в общей области должна появиться текстовая подсказка об ошибке, например: «Это поле обязательно для заполнения». Поле должно быть подсвечено. Сообщение об ошибке должно указывать на неверный формат (например, «Введите число»). Поле должно быть подсвечено. Сообщение об ошибке должно указывать на превышение длины. Ввод должен быть обрезан или заблокирован на уровне лимита. Сообщения об ошибках должны быть понятными и исчезать после начала ввода корректных данных.
Тест-кейс TC-GUI-03 – корректность отображения и функциональность системы комментариев:
Предусловия: пользователь авторизован как Рецензент, открыт интерфейс рецензирования ТЗ.
Шаги: выделить любой фрагмент текста в одном из разделов ТЗ. Нажать всплывающую иконку «Добавить комментарий» (или аналогичную). Убедиться, что появилось модальное окно или inline-форма рядом с выделенным текстом. Ввести текст комментария и нажать «Сохранить». Проверить, где и как отобразился сохраненный комментарий (например, в боковой панели или в виде inline-примечания). Навести курсор или кликнуть на отображенный комментарий. Проверить наличие и работоспособность кнопки «Отметить как исправленное» (для Автора).
Ожидаемый результат: иконка появляется рядом с выделением. Форма для ввода отображается корректно, комментарий сохраняется. Комментарий визуально привязан к месту выделения (например, цветной маркер в тексте и запись в панели со ссылкой на раздел). Должна быть какая-либо интерактивная обратная связь (подсветка). Для автора ТЗ должна быть доступна кнопка изменения статуса комментария.
Баг-репорты
Баг-репорт BR-GUI-01 (ID: BR-GUI-01):
Заголовок: на мобильном разрешении кнопки действий в карточке проекта накладываются на текст.
Описание: на странице «Мои проекты» при ширине экрана менее 576px кнопки «Открыть», «Создать ТЗ», расположенные в карточке проекта, наезжают на текст описания проекта, делая его нечитаемым.
Шаги воспроизведения: авторизоваться как Автор. Перейти на страницу /projects/. Уменьшить ширину окна браузера до 575px или эмулировать мобильное устройство. Посмотреть на карточку любого проекта, содержащего описание.
Фактический результат: блок с кнопками перекрывает часть текста описания.
Ожидаемый результат: элементы интерфейса должны быть перекомпонованы (например, кнопки переносятся на новую строку) так, чтобы не перекрывать контент.
Серьезность: S4 – незначительная (Minor). Функциональность кнопок не нарушена, но ухудшено восприятие информации.
Приоритет: низкий.
Баг-репорт BR-GUI-02 (ID: BR-GUI-02):
Заголовок: неочевидное состояние обязательного поля после неудачной попытки отправки.
Описание: при попытке отправить ТЗ на согласование с незаполненным обязательным полем система подсвечивает поле красной рамкой, но текст подсказки об ошибке имеет низкую контрастность (серый на светло-сером) и плохо заметен.
Шаги воспроизведения: открыть ТЗ в конструкторе. Оставить поле «Наименование системы» пустым. Нажать «Отправить на согласование».
Фактический результат: поле обведено тонкой красной линией. Под полем мелким серым шрифтом выведен текст «Обязательное поле».
Ожидаемый результат: сообщение об ошибке должно быть четко видимым (например, красным цветом с достаточным размером шрифта и/или иконкой-предупреждением).
Серьезность: S4 – незначительная (Minor). Логика работы не нарушена, но пользователь может не заметить причину ошибки.
Приоритет: низкий.
Баг-репорт BR-GUI-03 (ID: BR-GUI-03):
Заголовок: отсутствует индикатор загрузки при выполнении длительных операций.
Описание: при нажатии на кнопку «Экспорт в DOCX» для большого документа или «Поиск по архиву» с обширными критериями интерфейс «замирает» без какой-либо обратной связи. Пользователь не понимает, обрабатывается ли его запрос или произошел сбой.
Шаги воспроизведения: открыть ТЗ с большим количеством текста и вложений. Нажать кнопку «Экспорт в DOCX». Наблюдать за интерфейсом в течение 3-5 секунд.
Фактический результат: кнопка остается в нажатом состоянии, но никакой анимации загрузки или сообщения «Идет обработка...» не отображается. Файл начинает скачиваться только через несколько секунд.
Ожидаемый результат: при инициировании операции, которая может занять более 1-2 секунд, должен появляться индикатор прогресса (спиннер, прогресс-бар) или блокирующее сообщение, информирующее пользователя о процессе.
Серьезность: S3 – значительная (Major). Отсутствие обратной связи ухудшает пользовательский опыт и может привести к повторным нажатиям и ошибкам.
Приоритет: средний.
Тестирование удобства использования (Usability Testing)
Тест план
Идентификатор тест-плана: TP-USABILITY-01.
Введение: тестирование удобства использования направлено на оценку степени понятности, эффективности и удовлетворенности, которые пользователи испытывают при взаимодействии с веб-сервисом «ТехЗадание-Конструктор». Цель – выявить потенциальные сложности в навигации, понимании интерфейса и выполнении ключевых задач, которые не были обнаружены в ходе функционального тестирования.
Объект тестирования: пользовательский интерфейс и пользовательский опыт (UX) веб-сервиса «ТехЗадание-Конструктор», версия 1.0.
Функции, которые будут протестированы:
интуитивность навигации и поиска функций;
понятность формулировок, названий кнопок, сообщений системы;
эффективность выполнения ключевых сценариев (создание ТЗ, согласование, поиск информации);
общее восприятие интерфейса, чистота и неперегруженность.
Функции, которые не будут протестированы: Техническая производительность системы, безопасность.
Тестовые подходы: оценочное (эвристическое) тестирование, основанное на общепринятых принципах юзабилити (Нильсена). Тестирование с привлечением 2-3 представителей целевой аудитории (студентов/сотрудников), не участвовавших в разработке, с наблюдением за их действиями и сбором обратной связи.
Критерии прохождения тестирования: основные задачи могут быть выполнены тестовыми пользователями без помощи сторонних подсказок. Критических проблем юзабилити, вызывающих непонимание или сбой в выполнении задачи, не выявлено. Полученная обратная связь в основном положительная или содержит конструктивные предложения по улучшению.
Критерии приостановления и возобновления тестирования: не применимо, так как тестирование является оценочным и не блокирует другие процессы.
Результаты тестирования: отчет с описанием проведенных сессий, перечнем выявленных проблем юзабилити с приоритетами и рекомендациями по их устранению.
Задачи тестирования: подготовка сценариев задач для пользователей, проведение тестовых сессий, наблюдение, интервью, анализ результатов.
Ресурсы системы: рабочее приложение на тестовом стенде, браузер, средства записи экрана (по возможности).
Обязанности: модератор (разработчик) – проведение сессии, наблюдение. Тестовый пользователь – выполнение заданных задач.
Роли и ответственность: ответственный за тестирование – студент-разработчик. Участники тестирования – студенты/коллеги.
Расписание: 24.12.2025.
Оценка рисков: субъективность оценки, небольшой размер выборки тестовых пользователей, возможная скованность участников.
Согласования: согласовано руководителем практики.
Тест-кейсы
Сценарий US-01 – создание и отправка на согласование первого ТЗ:
Контекст для пользователя: «вы – студент, которому необходимо оформить техническое задание для своей выпускной квалификационной работы. Это ваш первый раз в этой системе».
Задача: создайте новый проект для вашей ВКР и оформите в нем техническое задание. Отправьте его на проверку научному руководителю.
Критерии успеха (для модератора): пользователь находит, как создать проект. Пользователь понимает, как начать создание ТЗ внутри проекта. Пользователь успешно выбирает подходящий шаблон. Пользователь заполняет несколько разделов и находит кнопку отправки на согласование.
Наблюдаемые метрики: время на выполнение задачи, количество ошибочных кликов, необходимость в подсказках, вербальные реакции («а где это?», «что это значит?»).
Сценарий US-02 – проверка поступившего ТЗ в качестве рецензента:
Контекст для пользователя: «вы – преподаватель. К вам на проверку поступило техническое задание от студента. Вам нужно его изучить, оставить замечание по конкретному разделу и вернуть документ на доработку».
Задача: найдите задание, ожидающее вашей проверки. Ознакомьтесь с документом, оставьте комментарий к разделу «Требования к функциональным характеристикам» и верните документ автору.
Критерии успеха (для модератора): пользователь быстро находит список своих задач. Пользователь понимает, как оставить комментарий к конкретному месту в тексте. Пользователь находит и использует кнопку «Вернуть на доработку».
Наблюдаемые метрики: понимание интерфейса комментариев, легкость навигации между разделами документа, ясность статусов.
Сценарий US-03 – поиск и просмотр старого, утвержденного ТЗ:
Контекст для пользователя: «месяц назад вы успешно согласовали и утвердили ТЗ для одного проекта. Теперь вам нужно найти этот документ, чтобы вспомнить детали».
Задача: найдите в системе утвержденное техническое задание для проекта «Тестовый проект ВКР» (или другого известного пользователю) и откройте его для просмотра.
Критерии успеха (для модератора): пользователь использует логичный для себя путь поиска (поиск по названию, фильтр по статусу «Утверждено», просмотр своих проектов). Пользователь успешно открывает документ и видит его финальное, утвержденное содержимое.
Наблюдаемые метрики: выбор стратегии поиска, количество попыток, удовлетворенность результатом.
Баг-репорты
Проблема USABILITY-01 (ID: U-01):
Заголовок: неочевидное расположение кнопки «Создать ТЗ» внутри проекта.
Описание: в ходе тестирования по сценарию US-01 два из трех пользователей не сразу заметили кнопку «Создать ТЗ» на странице детального просмотра проекта. Они искали эту функцию в основном меню или в шапке страницы. Кнопка находится в верхнем правом углу карточки с общей информацией о проекте и визуально не выделяется.
Контекст: страница детального просмотра проекта (/projects/<id>/).
Влияние на пользователя: замедляет выполнение ключевой задачи, вызывает легкую фрустрацию («Я не могу найти, где начать»).
Рекомендация по улучшению: усилить визуальный вес кнопки (размер, контрастный цвет). Продублировать действие в более ожидаемом месте – например, добавить крупную кнопку «+ Создать ТЗ» в заголовке раздела со списком ТЗ этого проекта. Возможно, добавить текстовую подсказку «Чтобы начать работу, создайте ТЗ» в пустом состоянии списка.
Приоритет улучшения: высокий (для новой функции).
Проблема USABILITY-02 (ID: U-02):
Заголовок: непонятная иконка для добавления комментария.
Описание: при тестировании сценария US-02 пользователи, выделив текст, видели появляющуюся панельку с иконкой. Никто из них не смог однозначно идентифицировать, что эта иконка (синий квадрат с плюсом или говорящий пузырек) означает «добавить комментарий». Один пользователь ожидал, что это кнопка «копировать».
Контекст: интерфейс рецензирования, выделение текста.
Влияние на пользователя: ключевая функция системы (контекстное комментирование) остается неочевидной, пользователи могут ее не обнаружить. Снижает эффективность обратной связи.
Рекомендация по улучшению: заменить абстрактную иконку на более понятную, например, на иконку с текстовой подписью «Комментарий» или использовать стандартную иконку в виде облачка с текстом. Добавить всплывающую подсказку (tooltip) с текстом «Добавить комментарий к выделенному» при наведении на иконку.
Приоритет улучшения: средний.
Проблема USABILITY-03 (ID: U-03):
Заголовок: отсутствие визуальной обратной связи при смене вкладок/разделов в конструкторе.
Описание: в конструкторе ТЗ, при нажатии на заголовок другого раздела текущий раздел сворачивается, а новый – открывается. Пользователи отмечали, что из-за этого «теряется фокус», не всегда сразу понятно, какой раздел сейчас активен, особенно если их несколько открыто.
Контекст: страница конструктора ТЗ.
Влияние на пользователя: может привести к путанице при заполнении длинного документа, ощущению дезориентации в структуре.
Рекомендация по улучшению: активный (открытый) раздел должен иметь более выраженное визуальное отличие от неактивных (например, более темный или цветной фон заголовка, левая цветная граница). Можно добавить плавную анимацию при переключении.
Приоритет улучшения: низкий.
Автоматизированное тестирование (Unit-тесты)
Помимо ручного функционального тестирования, для обеспечения надежности и регрессионной устойчивости критически важных компонентов системы были разработаны автоматизированные тесты с использованием встроенного фреймворка Django TestCase. Тесты охватывают ключевые бизнес-сценарии и проверяют корректность работы моделей, бизнес-логики workflow и системы аутентификации.
Тест-план автоматизированного тестирования
Идентификатор тест-плана: TP-UNIT-01.
Объект тестирования: модули приложений accounts, specs, workflow веб-сервиса «ТехЗадание-Конструктор».
Цель тестирования: обеспечить автоматическую проверку корректности работы критической бизнес-логики при каждом изменении кода, предотвратить регрессионные ошибки.
Объем тестирования:
Модели данных и их методы (валидация, свойства);
Бизнес-логика workflow (создание задач, смена статусов, проверка прав);
Сервис экспорта документов (проверка структуры генерируемого файла);
Система аутентификации и проверки прав доступа.
Инструменты: встроенный фреймворк Django TestCase, библиотека coverage.py для оценки покрытия кода тестами.
Критерии прохождения: все тесты должны выполняться успешно (без ошибок и падений). Покрытие критического кода тестами должно составлять не менее 70%.
Критерии приостановления: при падении любого теста дальнейшее развертывание кода в промышленную эксплуатацию блокируется до исправления.
Реализованные тест-кейсы
Тест-кейс TC-UNIT-01 – Проверка модели пользователя и ролей
# apps/accounts/tests.py
from django.test import TestCase
from django.contrib.auth import get_user_model
from apps.accounts.models import Role
class UserModelTests(TestCase):
def setUp(self):
self.role_author = Role.objects.create(name='author', description='Автор')
self.user = get_user_model().objects.create_user(
email='test@example.com',
password='testpass123',
full_name='Тестовый Пользователь',
role=self.role_author
)
def test_user_creation(self):
"""Тест создания пользователя с кастомными полями"""
self.assertEqual(self.user.email, 'test@example.com')
self.assertEqual(self.user.full_name, 'Тестовый Пользователь')
self.assertEqual(self.user.role.name, 'author')
self.assertTrue(self.user.check_password('testpass123'))
def test_user_properties(self):
"""Тест свойств пользователя для проверки ролей"""
self.assertTrue(self.user.is_author_role)
self.assertFalse(self.user.is_admin)
self.assertFalse(self.user.is_reviewer_role)
Тест-кейс TC-UNIT-02 – Проверка валидации названия ТЗ
# apps/specs/tests.py
from django.test import TestCase
from django.core.exceptions import ValidationError
from apps.specs.models import TechnicalSpec, Template
from apps.projects.models import Project
from apps.accounts.models import Role, User
class TechnicalSpecValidationTests(TestCase):
def setUp(self):
# Создание тестовых данных
role_author = Role.objects.create(name='author', description='Автор')
self.author = User.objects.create_user(
email='author@test.com',
password='testpass123',
full_name='Автор',
role=role_author
)
self.project = Project.objects.create(
title='Тестовый проект',
author=self.author
)
self.template = Template.objects.create(
name='Тестовый шаблон',
based_on_standard='ГОСТ 34.602-2020',
structure={'sections': []}
)
def test_valid_title(self):
"""Тест корректного названия ТЗ"""
spec = TechnicalSpec(
project=self.project,
template=self.template,
title='Корректное название ТЗ (версия 1.0)'
)
# Не должно вызывать исключений
spec.full_clean()
def test_invalid_title_with_forbidden_chars(self):
"""Тест названия с запрещенными символами"""
spec = TechnicalSpec(
project=self.project,
template=self.template,
title='Название с / слешем и "кавычками"'
)
with self.assertRaises(ValidationError):
spec.full_clean()
def test_title_too_short(self):
"""Тест слишком короткого названия"""
spec = TechnicalSpec(
project=self.project,
template=self.template,
title='А'
)
with self.assertRaises(ValidationError):
spec.full_clean()
Тест-кейс TC-UNIT-03 – Проверка бизнес-логики workflow
# apps/workflow/tests.py
from django.test import TestCase
from django.utils import timezone
from datetime import timedelta
from apps.workflow.models import ApprovalStatus, ReviewTask, Comment
from apps.specs.models import TechnicalSpec, Template, DocumentVersion
from apps.projects.models import Project
from apps.accounts.models import Role, User
class WorkflowTests(TestCase):
def setUp(self):
# Создание ролей
self.role_author = Role.objects.create(name='author', description='Автор')
self.role_reviewer = Role.objects.create(name='reviewer', description='Рецензент')
# Создание пользователей
self.author = User.objects.create_user(
email='author@test.com',
password='testpass123',
full_name='Автор',
role=self.role_author
)
self.reviewer = User.objects.create_user(
email='reviewer@test.com',
password='testpass123',
full_name='Рецензент',
role=self.role_reviewer
)
# Создание статусов
self.draft_status = ApprovalStatus.objects.create(
name='Черновик',
code='draft',
order_num=1
)
self.review_status = ApprovalStatus.objects.create(
name='На проверке',
code='review',
order_num=2
)
# Создание проекта и ТЗ
self.project = Project.objects.create(
title='Тестовый проект',
author=self.author
)
self.template = Template.objects.create(
name='Тестовый шаблон',
based_on_standard='ГОСТ 34.602-2020',
structure={'sections': []}
)
self.spec = TechnicalSpec.objects.create(
project=self.project,
template=self.template,
title='Тестовое ТЗ'
)
# Создание версии документа
self.version = DocumentVersion.objects.create(
spec=self.spec,
version_number=1,
content={'sections': []},
status=self.draft_status,
created_by=self.author
)
self.spec.current_version = self.version
self.spec.save()
def test_create_review_task(self):
"""Тест создания задачи на рецензирование"""
task = ReviewTask.objects.create(
spec=self.spec,
assigned_to=self.reviewer,
status='pending',
due_date=timezone.now() + timedelta(days=3)
)
self.assertEqual(task.spec, self.spec)
self.assertEqual(task.assigned_to, self.reviewer)
self.assertEqual(task.status, 'pending')
self.assertIsNotNone(task.due_date)
def test_change_spec_status(self):
"""Тест смены статуса документа"""
self.version.status = self.review_status
self.version.save()
self.spec.refresh_from_db()
self.assertEqual(self.spec.current_version.status, self.review_status)
def test_add_comment_to_version(self):
"""Тест добавления комментария к версии документа"""
task = ReviewTask.objects.create(
spec=self.spec,
assigned_to=self.reviewer,
status='pending'
)
comment = Comment.objects.create(
task=task,
section_path='1.2.3_requirements',
text='Тестовый комментарий',
created_by=self.reviewer
)
self.assertEqual(comment.text, 'Тестовый комментарий')
self.assertEqual(comment.section_path, '1.2.3_requirements')
self.assertEqual(comment.created_by, self.reviewer)
self.assertFalse(comment.resolved)
Тест-кейс TC-UNIT-04 – Проверка проверки прав доступа
# apps/core/tests/test_permissions.py
from django.test import TestCase
from apps.core.mixins import PermissionService
from apps.accounts.models import Role, User
from apps.projects.models import Project, ProjectMember
from apps.specs.models import TechnicalSpec, Template, DocumentVersion
from apps.workflow.models import ApprovalStatus
class PermissionServiceTests(TestCase):
def setUp(self):
# Создание ролей
self.role_admin = Role.objects.create(name='admin', description='Администратор')
self.role_author = Role.objects.create(name='author', description='Автор')
self.role_reviewer = Role.objects.create(name='reviewer', description='Рецензент')
# Создание пользователей
self.admin = User.objects.create_user(
email='admin@test.com',
password='testpass123',
full_name='Админ',
role=self.role_admin
)
self.author = User.objects.create_user(
email='author@test.com',
password='testpass123',
full_name='Автор',
role=self.role_author
)
self.reviewer = User.objects.create_user(
email='reviewer@test.com',
password='testpass123',
full_name='Рецензент',
role=self.role_reviewer
)
# Создание проекта
self.project = Project.objects.create(
title='Тестовый проект',
author=self.author
)
# Добавление рецензента как участника проекта
ProjectMember.objects.create(
project=self.project,
user=self.reviewer,
role='reviewer'
)
# Создание ТЗ
self.template = Template.objects.create(
name='Тестовый шаблон',
based_on_standard='ГОСТ',
structure={'sections': []}
)
self.draft_status = ApprovalStatus.objects.create(
name='Черновик',
code='draft',
order_num=1
)
self.spec = TechnicalSpec.objects.create(
project=self.project,
template=self.template,
title='Тестовое ТЗ'
)
self.version = DocumentVersion.objects.create(
spec=self.spec,
version_number=1,
content={'sections': []},
status=self.draft_status,
created_by=self.author
)
self.spec.current_version = self.version
self.spec.save()
def test_admin_has_full_access(self):
"""Тест: администратор имеет полный доступ"""
self.assertTrue(PermissionService.can_view_spec(self.admin, self.spec))
self.assertTrue(PermissionService.can_edit_spec(self.admin, self.spec))
self.assertTrue(PermissionService.can_delete_spec(self.admin, self.spec))
self.assertTrue(PermissionService.can_start_review(self.admin, self.spec))
def test_author_can_edit_draft(self):
"""Тест: автор может редактировать черновик"""
self.assertTrue(PermissionService.can_edit_spec(self.author, self.spec))
self.assertTrue(PermissionService.can_start_review(self.author, self.spec))
def test_reviewer_cannot_edit_spec(self):
"""Тест: рецензент не может редактировать ТЗ"""
self.assertFalse(PermissionService.can_edit_spec(self.reviewer, self.spec))
def test_reviewer_can_review_assigned_spec(self):
"""Тест: рецензент может проверять назначенное ТЗ"""
# Создаем задачу для рецензента
from apps.workflow.models import ReviewTask
ReviewTask.objects.create(
spec=self.spec,
assigned_to=self.reviewer,
status='pending'
)
self.assertTrue(PermissionService.can_review(self.reviewer, self.spec))
Тест-кейс TC-UNIT-05 – Проверка генерации безопасного имени файла
# apps/specs/tests/test_export.py
from django.test import TestCase
from apps.specs.models import TechnicalSpec
from apps.projects.models import Project
from apps.accounts.models import Role, User
class ExportFilenameTests(TestCase):
def setUp(self):
role = Role.objects.create(name='author', description='Автор')
self.author = User.objects.create_user(
email='author@test.com',
password='testpass123',
full_name='Автор',
role=role
)
self.project = Project.objects.create(
title='Тестовый проект',
author=self.author
)
def test_safe_filename_generation(self):
"""Тест генерации безопасного имени файла"""
spec = TechnicalSpec(
project=self.project,
title='Название с пробелами и / слешем'
)
# Мокируем версию для теста
spec.current_version = type('obj', (object,), {'version_number': 1})
filename = spec.get_safe_filename()
# Проверяем, что недопустимые символы удалены
self.assertNotIn('/', filename)
self.assertNotIn('"', filename)
self.assertIn('пробелами', filename)
self.assertIn('_v1.docx', filename)
Результаты выполнения тестов
Автоматизированные тесты запускаются командой python manage.py test и выполняются при каждом коммите в репозиторий. По состоянию на 15.02.2026:
Всего тестов: 32.
Успешно пройдено: 30.
Упало: 2 (исправлены в процессе разработки).
Текущее состояние: 32/32 успешно.
Покрытие кода тестами: 78% (измерено с помощью coverage.py).
Ниже приведен результат запуска тестов после исправления обнаруженных проблем (Рисунок 3.1).
Рисунок 3.1 – Выполнение тестов с помощью Django TestCase
Выявленные и исправленные в процессе написания тестов дефекты:
Область применения
Настоящее руководство администратора (далее – РА) предназначено для сотрудников Департамента информационных технологий (ДИТ) ЧОУ ВО «Московский университет им. С.Ю. Витте», ответственных за установку, первоначальную настройку, развертывание, интеграцию, администрирование и техническое сопровождение веб-сервиса «ТехЗадание-Конструктор». РА описывает процедуры, выполняемые на серверах приложения и базы данных.
Краткое описание возможностей
Веб-сервис «ТехЗадание-Конструктор» представляет собой корпоративную информационную систему для автоматизации бизнес-процесса формирования, согласования и утверждения технических заданий в соответствии с ГОСТ 34.602-2020. Ключевые административные возможности:
управление пользователями и ролевой моделью доступа (RBAC);
управление библиотекой шаблонов ТЗ (создание, редактирование JSON-структуры);
настройка маршрутов согласования (workflow);
мониторинг системы через журнал событий (EventLog) и интерфейс администратора Django;
интеграция с корпоративной почтовой системой для отправки уведомлений;
выполнение резервного копирования и восстановления данных.
Уровень подготовки пользователя
Пользователь РА (системный администратор) должен обладать следующими знаниями и навыками:
опыт администрирования ОС Linux (Ubuntu/Debian);
базовые знания веб-серверов (Nginx/Apache), СУБД MySQL и языка SQL;
умение работать с командной строкой, системами контроля версий (Git);
понимание основ сетевой безопасности и модели развертывания веб-приложений;
ознакомление с основами фреймворка Django будет преимуществом.
Перечень эксплуатационной документации
Перед началом работы с системой администратору необходимо ознакомиться с:
техническое задание на создание АС «ТехЗадание-Конструктор»;
проектная документация (схемы данных, архитектурные диаграммы);
план инсталляции и развертывания (раздел 3.2 ВКР);
план интеграции с почтовой системой (раздел 3.3 ВКР).
Назначение и условия применения
Назначение
Средство автоматизации предназначено для автоматизации видов деятельности, связанных с документооборотом технических заданий:
формализация требований к ИТ-проектам, ВКР, НИР;
обеспечение соответствия документации ГОСТ 34.602-2020;
организация электронного согласования документов между ролями: Инициатор (Автор), Рецензент (Руководитель/Эксперт), Утверждающее лицо;
централизованное хранение версий документов, комментариев и истории действий.
Условия применения
Для обеспечения применения системы в соответствии с назначением необходимо соблюдение следующих условий:
Технические средства – виртуальный или физический сервер x86-64. Рекомендуемая конфигурация: 2+ ядра CPU, 4+ ГБ ОЗУ, 50+ ГБ SSD.
Программные средства:
операционная система: Ubuntu Server 22.04 LTS или аналогичная;
веб-сервер: Nginx 1.18+;
система управления базами данных: MySQL 8.0+;
интерпретатор: Python 3.9+;
система контроля версий: Git.
Операционная среда – на сервере должно быть настроено сетевое подключение к корпоративной сети университета, разрешающее входящие HTTP/HTTPS-запросы и исходящие SMTP-запросы к почтовому серверу.
Входная информация / База данных – для первоначального запуска требуется пустая база данных MySQL. Для промышленной эксплуатации необходима актуальная резервная копия данных из тестового контура или процедура миграции данных.
Подготовка специалистов – администратор должен пройти инструктаж по общим принципам работы системы и ознакомиться с данным руководством.
Подготовка к работе
Состав и содержание дистрибутивного носителя данных
Дистрибутив системы представлен в виде Git-репозитория. Основные элементы:
requirements.txt – файл зависимостей Python;
manage.py – скрипт управления Django-проектом;
каталог config/ – настройки проекта (Django settings);
каталоги apps/ – исходный код приложений (accounts, specs, workflow и др.);
каталог scripts/ – вспомогательные скрипты для администрирования (бэкап, деплой);
каталог docs/ – документация;
файлы конфигурации для Nginx (techspec_nginx.conf).
Порядок загрузки данных и программ
Получение кода: git clone https://gitflic.ru/project/borovskiy/auto_tech_spec.git
Установка зависимостей: в каталоге проекта выполнить pip install -r requirements.txt внутри активированного виртуального окружения Python.
Настройка переменных окружения: создать файл .env в корне проекта и установить критичные параметры (секретный ключ Django, данные для подключения к БД, SMTP-настройки). Пример содержимого .env файла приведен в Приложении А.
Применение миграций БД: python manage.py migrate.
Создание суперпользователя: python manage.py createsuperuser (для доступа в админ-панель).
Сбор статических файлов: python manage.py collectstatic --noinput
Порядок проверки работоспособности
Запуск тестового сервера: python manage.py runserver 0.0.0.0:8000
Проверка доступности: открыть в браузере http://<IP_сервера>:8000/. Должна загрузиться стартовая страница.
Проверка админ-панели: перейти по адресу http://<IP_сервера>:8000/admin/ и войти под учетной записью суперпользователя. Убедиться в доступности разделов.
Проверка интеграции SMTP: в админ-панели, в разделе «Система», найти и выполнить действие «Отправить тестовое письмо», указав корректный email.
Описание операций
Операция АДМ-01: регистрация нового пользователя и назначение роли.
Наименование: добавление пользователя в систему.
Условия: администратор авторизован в интерфейсе /admin/. Новая учетная запись не должна существовать в системе.
Подготовительные действия: получить от руководителя подразделения или учебного отдела данные нового пользователя (ФИО, email, требуемая роль).
Основные действия:
в админ-панели перейти в раздел «Пользователи»;
нажать кнопку «Добавить пользователя +»;
заполнить обязательные поля: «Адрес электронной почты» (логин), «ФИО». Ввести и подтвердить пароль во временном поле или использовать функцию «Сгенерировать пароль»;
в блоке «Права» выбрать соответствующую «Роль» из выпадающего списка (Автор, Рецензент, Утверждающий);
нажать кнопку «Сохранить». Система автоматически отправит приветственное письмо с инструкциями на указанный email (если интеграция SMTP настроена).
Заключительные действия: проинформировать пользователя о создании учетной записи и отправить ему временные данные для входа (если пароль был сгенерирован системой).
Ресурсы: время администратора – 3-5 минут.
Операция АДМ-02: настройка шаблона технического задания.
Наименование: создание или изменение структуры шаблона ТЗ.
Условия: администратор авторизован. Требуется актуальная версия стандарта ГОСТ 34.602-2020.
Подготовительные действия: определить структуру нового шаблона или подготовить изменения к существующему.
Основные действия:
в админ-панели перейти в раздел «шаблоны»;
выбрать существующий шаблон для редактирования или нажать «добавить шаблон +»;
заполнить поле «название» и «описание»;
в поле «структура (json)» внести валидный json-объект, описывающий разделы. пример структуры приведен в приложении Б;
установить или снять флажок «активен»;
нажать «сохранить».
Заключительные действия: протестировать созданный/измененный шаблон, создав через интерфейс пользователя пробное ТЗ.
Ресурсы: время администратора – 10-30 минут в зависимости от сложности шаблона.
Операция АДМ-03: настройка интеграции с корпоративной почтой (SMTP).
Наименование: конфигурация параметров отправки электронных уведомлений.
Условия: получены от администратора почтовой системы учетные данные для специального ящика (noreply-techspec@muiv.ru): SMTP-хост, порт, логин, пароль.
Подготовительные действия: остановить сервис. Создать или отредактировать файл .env на сервере приложения.
Основные действия:
В файле .env добавить или изменить следующие переменные:
EMAIL_HOST=smtp.mail.muiv.ru
EMAIL_PORT=587
EMAIL_USE_TLS=True
EMAIL_HOST_USER=noreply-techspec@muiv.ru
EMAIL_HOST_PASSWORD=<секретный_пароль_или_токен>
DEFAULT_FROM_EMAIL=noreply-techspec@muiv.ru
Сохранить файл .env.
Перезапустить сервисы: sudo systemctl restart <имя процесса>
Заключительные действия: выполнить операцию проверки работоспособности (п. 3.3, шаг 4) для подтверждения корректности настройки.
Ресурсы: время администратора – 10 минут.
Аварийные ситуации
Действия при отказе сервера приложений или БД
Симптомы: веб-интерфейс недоступен (ошибки 502, 503, 500). Ошибки в логах MySQL.
Действия:
проверить статус сервисов: sudo systemctl status mysql;
просмотреть логи ошибок для определения причины;
перезапустить проблемный сервис: sudo systemctl restart <имя_сервиса>;
если перезапуск не помогает, проверить доступность дискового пространства (df -h) и загрузку системы (top);
в случае критического сбоя БД выполнить восстановление из последней резервной копии (см. скрипт scripts/restore_db.sh).
Действия по восстановлению данных при отказе носителей
Процедура: регулярное (ежедневное) резервное копирование осуществляется скриптом scripts/backup.sh, который создает дамп базы данных и архивирует каталог с медиафайлами. Архивы хранятся на отдельном сетевом хранилище.
Действия по восстановлению:
остановить приложение;
восстановить дамп БД: mysql -u <user> -p tech_spec_db < backup_YYYYMMDD.sql;
распаковать архив с медиафайлами в соответствующую директорию;
запустить приложение и проверить целостность данных.
Действия при обнаружении несанкционированного доступа
Симптомы: подозрительная активность в логах (/var/log/nginx/access.log с множеством неудачных попыток входа), изменения данных, не соответствующие бизнес-процессу.
Действия:
немедленно изолировать систему (заблокировать входящий трафик на уровне брандмауэра, кроме IP-адресов администраторов);
заблокировать скомпрометированные учетные записи пользователей через админ-панель;
проанализировать логи для определения вектора атаки;
сменить все системные пароли и секретные ключи (в .env);
после устранения угрозы разблокировать систему и уведомить руководство.
Рекомендации по освоению
Для быстрого освоения системы рекомендуется выполнить контрольный пример, имитирующий полный цикл работы:
создание тестовых ролей: в админ-панели создать трех тестовых пользователей с ролями «Автор», «Рецензент», «Утверждающий»;
создание проекта и ТЗ: войти под Автором, создать проект «Контрольный пример», в нем – новое ТЗ на основе шаблона «ГОСТ 34.602-2020 (Базовый)»;
запуск согласования: заполнить несколько разделов и отправить ТЗ на согласование;
проведение рецензирования: войти под Рецензентом, найти задачу во «Входящих», оставить комментарий к разделу и вернуть ТЗ на доработку;
доработка и утверждение: войти под Автором, исправить ТЗ по комментарию, повторно отправить на согласование. Войти под Рецензентом и принять ТЗ. Войти под Утверждающим и утвердить документ;
экспорт: убедиться, что утвержденное ТЗ можно экспортировать в формате .docx.
Правила запуска и выполнения данного примера описаны в сценариях тестирования удобства использования (раздел 3.1.4 ВКР). Освоение рекомендуется проводить на тестовом стенде (Green-окружении), изолированном от производственных данных.
Приложение А. Пример файла конфигурации .env
# Django
SECRET_KEY='django-insecure-ваш_очень_длинный_секретный_ключ'
DEBUG=False
ALLOWED_HOSTS=.muiv.ru,localhost,127.0.0.1,[::1]
# Database
DB_NAME=tech_spec_db
DB_USER=tech_spec_user
DB_PASSWORD=сильный_пароль
DB_HOST=localhost
DB_PORT=3306
# Email (SMTP)
EMAIL_HOST=smtp.mail.muiv.ru
EMAIL_PORT=587
EMAIL_USE_TLS=True
EMAIL_HOST_USER=noreply-techspec@muiv.ru
EMAIL_HOST_PASSWORD=пароль_от_почты
DEFAULT_FROM_EMAIL=noreply-techspec@muiv.ru
Приложение Б. Пример структуры шаблона ТЗ в формате JSON
json
{
"sections": [
{
"id": "1",
"title": "Общие сведения",
"required": true,
"description": "Общая информация о разработке",
"fields": [
{"type": "text", "name": "full_system_name", "label": "Полное наименование системы", "required": true},
{"type": "text", "name": "short_system_name", "label": "Краткое наименование системы", "required": true}
]
},
{
"id": "2",
"title": "Назначение разработки",
"required": true,
"description": "Цели и задачи создания системы",
"fields": [
{"type": "textarea", "name": "purpose", "label": "Назначение системы", "required": true, "rows": 4}
]
}
]
}
Приложение 3. Руководство пользователя корпоративной информационной системы «ТехЗадание-Конструктор»
Область применения
Настоящее руководство пользователя (РП) предназначено для сотрудников и обучающихся ЧОУ ВО «Московский университет им. С.Ю. Витте», использующих веб-сервис «ТехЗадание-Конструктор» для формирования, согласования и утверждения технических заданий на разработку программного обеспечения, выполнение выпускных квалификационных работ (ВКР) и научно-исследовательских работ (НИР).
Краткое описание возможностей
Система позволяет:
создавать проекты и технические задания на основе шаблонов, соответствующих ГОСТ 34.602-2020;
заполнять разделы ТЗ в интуитивном веб-конструкторе;
направлять документы на согласование по электронному маршруту (workflow);
получать и оставлять контекстные комментарии к разделам документа;
отслеживать статус согласования в реальном времени;
экспортировать утвержденные ТЗ в формате Microsoft Word (.docx).
Уровень подготовки пользователя
Пользователь должен уметь:
работать с веб-браузером (Google Chrome, Mozilla Firefox и т.п.);
использовать стандартные элементы интерфейса: кнопки, поля ввода, ссылки;
иметь базовые навыки работы с текстовыми редакторами;
знать свой корпоративный адрес электронной почты (@muiv.ru) и пароль для входа в систему.
Перечень эксплуатационной документации
Для понимания общих принципов работы системы рекомендуется ознакомиться с настоящим руководством. В случае возникновения технических проблем, не описанных в РП, следует обращаться к системному администратору или в службу технической поддержки ДИТ.
Назначение и условия применения
Назначение
Система предназначена для автоматизации следующих видов деятельности:
подготовка проектной документации (технических заданий);
организация электронного согласования документов между исполнителями (студентами, сотрудниками), руководителями, экспертами и утверждающими лицами;
обеспечение единого формата и соответствия документации государственным стандартам;
Условия применения
Для работы с системой необходимо:
технические средства: персональный компьютер, ноутбук или планшет с доступом в сеть Интернет.
программные средства: веб-браузер последней версии (рекомендуется Google Chrome, Mozilla Firefox, Microsoft Edge).
операционная среда: доступ к корпоративной сети университета или Интернету.
входная информация: учетные данные (логин и пароль), выданные администратором системы. Логином является корпоративный адрес электронной почты (ваше_имя@muiv.ru).
подготовка специалистов: пользователю достаточно ознакомиться с данным руководством.
Подготовка к работе
Состав и содержание дистрибутивного носителя данных
Система является веб-сервисом и не требует установки программного обеспечения на компьютер пользователя. Доступ осуществляется через браузер по адресу, предоставленному администратором (например, https://techspec.muiv.ru).
Порядок загрузки данных и программ
Загрузка не требуется. Для начала работы необходимо открыть браузер и перейти по рабочему адресу системы.
Порядок проверки работоспособности
Откройте браузер и перейдите по адресу системы (например, https://techspec.muiv.ru).
На открывшейся странице должна отобразиться форма входа с полями «Email» и «Пароль». Если отображается главная страница, значит, вы уже авторизованы.
Для проверки введите свои учетные данные и нажмите кнопку «Войти». При успешном входе вы будете перенаправлены на главную страницу (Дашборд).
Описание операций
Операция ПОЛЬЗ-01: Вход в систему.
Наименование: авторизация пользователя.
Условия: пользователь имеет активную учетную запись и знает свои логин (email) и пароль.
Подготовительные действия: открыть браузер и перейти по адресу системы.
Основные действия:
на странице входа в поле «Email» введите ваш корпоративный адрес электронной почты (например, ivanov@muiv.ru);
в поле «Пароль» введите ваш пароль;
нажмите синюю кнопку «Войти».
Заключительные действия: если данные введены верно, вы будете перенаправлены на главную страницу. В правом верхнем углу будет отображаться ваше имя.
Ресурсы: время выполнения – менее 1 минуты.
Операция ПОЛЬЗ-02: Создание нового технического задания.
Наименование: инициация процесса оформления ТЗ.
Условия: пользователь авторизован и имеет роль «Автор» или «Руководитель». У пользователя есть идея проекта, для которого требуется ТЗ.
Подготовительные действия: определить название и краткое описание будущего проекта.
Основные действия:
в главном меню слева нажмите на пункт «Проекты»;
на странице со списком проектов нажмите зеленую кнопку «+ Создать проект» в правом верхнем углу;
в открывшейся форме заполните поле «Название проекта» (обязательно) и при необходимости поле «Описание»;
нажмите кнопку «Сохранить». Вы вернетесь к списку проектов.
в карточке только что созданного проекта нажмите кнопку «Создать ТЗ»;
в всплывающем окне выберите из списка подходящий шаблон (например, «ГОСТ 34.602-2020 (Базовый для ВКР)») и нажмите кнопку «Создать».
Заключительные действия: вы будете перенаправлены в Конструктор ТЗ – интерфейс для заполнения разделов документа. Название ТЗ по умолчанию будет соответствовать названию проекта.
Ресурсы: время выполнения – 2-3 минуты.
Операция ПОЛЬЗ-03: Заполнение раздела ТЗ в конструкторе.
Наименование: внесение содержательной информации в документ.
Условия: пользователь находится в Конструкторе ТЗ (после операции ПОЛЬЗ-02 или при редактировании существующего ТЗ).
Подготовительные действия: подготовить текстовое содержание для заполняемого раздела.
Основные действия:
в центре страницы расположены разделы документа. Нажмите на заголовок нужного раздела (например, «1. Общие сведения»), чтобы развернуть его;
в развернувшемся блоке вы увидите поля для заполнения. Поля, отмеченные красной звездочкой (*), являются обязательными;
введите требуемую информацию в текстовые поля. Для загрузки файла (например, схемы) нажмите кнопку «Выберите файл» в соответствующем блоке;
для сохранения введенных данных (создания черновика) нажмите синюю кнопку «Сохранить черновик» внизу страницы. Система сохранит данные автоматически каждые 30 секунд.
Заключительные действия: после заполнения всех необходимых разделов и нажатия «Сохранить черновик» вы увидите зеленое всплывающее уведомление «Черновик сохранен».
Ресурсы: время зависит от объема информации.
Операция ПОЛЬЗ-04: Отправка ТЗ на согласование.
Наименование: запуск процесса проверки и утверждения документа.
Условия: ТЗ находится в статусе «Черновик». Все обязательные поля (отмеченные *) заполнены. Пользователь является автором ТЗ или имеет соответствующие права.
Подготовительные действия: проверить заполнение всех обязательных полей.
Основные действия:
убедитесь, что вы находитесь в Конструкторе ТЗ;
в правом верхнем углу страницы найдите и нажмите оранжевую кнопку «Отправить на согласование»;
в появившемся диалоговом окне подтвердите действие, нажав кнопку «Да, отправить».
Заключительные действия: статус документа изменится на «На проверке». Вы и назначенные рецензенты получите уведомления по электронной почте. Кнопка редактирования станет неактивной до возврата документа на доработку.
Ресурсы: время выполнения – менее 1 минуты.
Операция ПОЛЬЗ-05: Рецензирование ТЗ (для Рецензента/Руководителя).
Наименование: проверка документа и оставление замечаний.
Условия: пользователь авторизован с ролью «Рецензент» или «Руководитель». В системе есть задачи, назначенные данному пользователю.
Подготовительные действия: открыть систему.
Основные действия:
на главной странице (Дашборде) в блоке «Требуют моего внимания» или в меню слева в разделе «Согласование» найдите карточку с нужным ТЗ;
нажмите на название ТЗ или кнопку «Проверить» в карточке;
вы перейдете на страницу рецензирования. Изучите документ;
чтобы оставить комментарий, выделите мышью фрагмент текста в любом разделе. Рядом с выделением появится небольшая панель. Нажмите на иконку «🗨️» (комментарий);
в открывшейся форме в поле «Текст комментария» введите ваше замечание или вопрос. Нажмите «Сохранить»;
после изучения документа внизу страницы в блоке «Решение по документу» выберите один из вариантов:
«Принять и перевести дальше» – если замечаний нет или они несущественны;
«Вернуть на доработку» – если требуются исправления. При этом можно добавить общий комментарий;
«Отклонить» – если документ не соответствует требованиям.
нажмите кнопку «Подтвердить решение».
Заключительные действий: статус документа изменится, автор получит уведомление. Если документ возвращен, он снова станет доступен автору для редактирования.
Ресурсы: время зависит от объема и сложности документа.
Операция ПОЛЬЗ-06: Экспорт утвержденного ТЗ в Word.
Наименование: скачивание финальной версии документа в формате .docx.
Условия: пользователь имеет доступ к ТЗ. ТЗ находится в статусе «Утверждено».
Подготовительные действия: открыть страницу с утвержденным ТЗ (из списка проектов или через поиск).
Основные действия:
на странице просмотра ТЗ над его содержимым найдите панель действий;
нажмите на кнопку «Экспорт в DOCX» (иконка в виде листа со стрелкой вниз);
браузер начнет скачивание файла. Файл будет назван по шаблону: ТЗ_<Название>_v<Номер версии>.docx.
Заключительные действия: откройте скачанный файл в Microsoft Word или другом совместимом редакторе для печати или дальнейшей работы.
Ресурсы: время зависит от размера документа и скорости сети.
Аварийные ситуации
Действия при невозможности входа в систему
Симптом: после ввода логина и пароля система выдает сообщение «Неверный email или пароль».
Действия:
проверьте, правильно ли введен email (логин) и пароль. Убедитесь, что не включен CAPS LOCK;
нажмите на ссылку «Забыли пароль?» под формой входа. Следуйте инструкциям в письме для сброса пароля;
если проблема не решается, обратитесь к администратору системы или в службу поддержки ДИТ.
Действия при потере введенных данных в конструкторе
Симптом: при заполнении ТЗ страница браузера неожиданно закрылась или обновилась, введенный текст пропал.
Действия:
снова откройте ТЗ в конструкторе. Система автоматически сохраняет черновики каждые 30 секунд;
если данные не восстановились, это означает, что с момента последнего изменения не прошло 30 секунд. Вводите данные заново;
рекомендация: при работе с большими текстами периодически нажимайте кнопку «Сохранить черновик» вручную или копируйте текст в буфер обмена перед переходом между разделами.
Действия при недоступности системы
Симптом: страница системы в браузере не загружается, отображается ошибка сети или сообщение «Сервер не отвечает».
Действия:
проверьте подключение вашего компьютера к сети Интернет/интранет;
попробуйте обновить страницу (клавиша F5);
если проблема сохраняется, возможно, проводятся плановые технические работы. Дождитесь уведомления от администратора или попробуйте зайти позднее;
если срочно требуется доступ к документу, свяжитесь с администратором системы.
Рекомендации по освоению
Для быстрого освоения системы рекомендуется выполнить контрольный пример:
войдите в систему под своей учетной записью (операция ПОЛЬЗ-01);
создайте тестовый проект с названием «Ознакомление с системой» (операция ПОЛЬЗ-02, шаги 1-4);
создайте в нем ТЗ, выбрав любой шаблон (операция ПОЛЬЗ-02, шаги 5-6);
заполните несколько полей в разделе «Общие сведения» (операция ПОЛЬЗ-03);
сохраните черновик, нажав соответствующую кнопку;
(опционально) если у вас есть права, попробуйте отправить ТЗ на согласование (операция ПОЛЬЗ-04).
Правила запуска: выполняйте действия последовательно, сверяясь с описанием операций и скриншотами в электронной версии руководства (доступны по ссылке Справка в самой системе). Все действия в контрольном примере безопасны и не затронут рабочие данные других пользователей.
