КУРСОВАЯ РАБОТА

Разработка веб-приложений (PHP)

PHP · SYMFONY · MYSQL

Как пользоваться пособием

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

Итог состоит из трех связанных результатов: проектной документации, работающего приложения и пояснительной записки. У них должны совпадать предметная область, требования, сущности, роли пользователей и реализованные сценарии. Красивый текст не заменяет программу; программа без объяснения проектных решений не заменяет курсовую.

Условные обозначения: FR - функциональное требование; NFR - нефункциональное требование; BR - бизнес-правило; UC - пользовательский сценарий; TC - тестовый сценарий; MVP - минимальная работоспособная версия с завершенным полезным процессом. Обозначения вводятся для связи документов, кода и проверок, а не для увеличения объема отчетности.1. Назначение курсовой и ожидаемый результат

1.1. Что именно вы разрабатываете

Нужно спроектировать и реализовать небольшую корпоративную информационную систему или законченную подсистему КИС. Она обслуживает процесс организации, объединяет связанные данные, различает полномочия сотрудников и дает информацию для контроля работы. Для курсовой достаточно одного подразделения или одного сквозного процесса. Не требуется создавать ERP для всего предприятия.

Подходящая задача: регистрация сервисных заявок, назначение исполнителя, выполнение работ, приемка результата и отчет по срокам. Недостаточная задача: сайт с описанием компании и формой обратной связи, если после отправки формы нет учета, обработки, ролей и состояния заявки.

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

1.2. Что должно быть сдано

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

1.3. Один проект, разные стороны оценивания

На КИС вы обосновываете автоматизацию: изучаете организацию и процессы, определяете требования, модели, данные, архитектуру и интеграции. На PHP превращаете этот проект в программу: реализуете интерфейс, бизнес-логику, хранение, безопасность, API, тестирование и развертывание.

Одна модель данных используется в обеих дисциплинах. Если в ходе программирования модель изменилась, исправьте ER-диаграмму, требования и описание. Не оставляйте в курсовой «идеальную» схему, которой нет в приложении.

2. Выбор темы и согласование объема

2.1. Как предложить собственную тему

Выбирайте процесс, который можете содержательно объяснить. Это может быть работа учебной лаборатории, небольшой компании, сервисной службы, студенческого объединения или условной организации. Реальный заказчик не обязателен; учебная организация допустима, если явно названа условной.

Формула темы: «Проектирование и разработка веб-подсистемы [процесс] для [организация или тип организации] на PHP/Symfony и MySQL». Например: «Проектирование и разработка веб-подсистемы учета и обработки заявок на обслуживание оборудования организации».

Не выбирайте тему только по знакомому слову «CRM». Сформулируйте проблему: заявки теряются, согласования не прослеживаются, сведения дублируются, ресурсы бронируются с конфликтами. Затем назовите конкретный результат автоматизации.

Тема согласуется до существенной разработки. Изменение границ фиксируется в паспорте и обсуждается с руководителем. Самовольное сокращение обязательного функционала в конце семестра недопустимо; своевременное согласованное уточнение задачи допустимо.

2.2. Паспорт проекта

Подготовьте 1-2 страницы: название; организация и статус исходных данных; проблема; цель; участники; два основных сценария; перечень сущностей; бизнес-правила; обязательный функционал MVP; исключения; предполагаемые отчеты; способ интеграции; репозиторий; контрольные этапы. Форма приведена в приложении А.

Включено в MVP означает: функция будет реализована и проверена. Перспектива развития означает: функция не входит в принимаемую версию. Нельзя описать перспективу в главе проектирования, а в заключении назвать ее реализованной.

2.3. Разумное ограничение сложности

Для индивидуальной работы рекомендуется 5-8 значимых предметных сущностей и 2 связанных бизнес-сценария. Пользователь, технический журнал и миграционная таблица сами по себе не доказывают достаточную предметную сложность. Набор уточняется с руководителем, без искусственного создания таблиц ради количества.

Удобный масштаб: заявка, категория, подразделение, назначение исполнителя, комментарий, вложение и история переходов. Избыточный масштаб: полноценный кадровый учет, бухгалтерия, зарплата, CRM, склад и производство одновременно.

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

3. Технический и функциональный профиль проекта

3.1. Базовый стек и архитектура

Базовая конфигурация: PHP 8.4, Symfony 7.4 LTS, Composer 2, MySQL 8.4, Doctrine ORM и Migrations, Twig, Symfony Forms/Validator и Security, PHPUnit, Git. Или более свежие версии. В README запишите фактически проверенные версии PHP, Symfony, MySQL, Composer и основных пакетов. Не заменяйте их формулировкой «последняя версия». Зависимости фиксируются composer.lock; после обновления повторно выполняются проверки. Совместимость дополнительных пакетов проверяется для выбранного окружения.

Базовый вариант реализации: модульный монолит, браузерный интерфейс на Twig, HTML/CSS/JavaScript и REST API. Бизнес-операции доступны через сервисы, а не дублируются в каждом контроллере. Изучение микросервисов в проектных лабораторных не означает обязанность реализовать несколько независимых серверов в курсовой. Альтернативы можно сравнить в главе 2, а реализовать один согласованный вариант.

Для сохранения технологической связи с PHP-лабораторными используются FOSRestBundle, NelmioApiDocBundle и Flysystem [6].

3.2. Минимальные признаки законченного приложения

3.3. Чего недостаточно

Недостаточны: статические страницы вместо хранения в MySQL; несколько несвязанных CRUD-таблиц без процесса; единственный суперпользователь; проверка прав только скрытием кнопок; Swagger с неработающими маршрутами; фиктивные тесты, всегда завершающиеся успехом; отчет, в котором все преимущества объявлены без проверки.

Не требуется внешнее подключение к реальной ERP. Для учебной интеграции допустим небольшой отдельный клиент или скрипт, который через документированный API читает или создает данные и обрабатывает ошибку. Он должен реально обращаться к вашему серверу. Названная в C4 внешняя система, к которой нет подключения, помечается как проектируемая, а не реализованная.

4. Как выполнять исследование и проектирование

4.1. Изучение предметной области

Опишите назначение организации, подразделения и участников процесса. Для условного предприятия достаточно рабочей модели, необходимой для вашей задачи.

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

Для учебного кейса честно укажите, что исходный процесс моделируется.

4.2. Процессы AS-IS и TO-BE

AS-IS описывает исходный порядок работы; TO-BE - порядок после внедрения предлагаемой системы. Сравнивайте один и тот же процесс с одинаковыми границами. Покажите участников, начало, действия, решения, передачу данных и завершение. Для этого практикума рекомендуется UML activity.

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

4.3. Требования и критерии приемки

Разделите требования на функциональные, нефункциональные и бизнес-правила. Предлагаемый ориентир: 10-15 FR, 5-7 NFR, минимум 3 BR. У каждого существенного требования должны быть идентификатор, формулировка, приоритет, критерий приемки и способ проверки.

Пример FR-04: «Руководитель назначает исполнителя для зарегистрированной заявки своего подразделения. После назначения система сохраняет исполнителя, меняет состояние и добавляет запись в историю». Критерий приемки: изменения видны после повторного открытия заявки; сотрудник без полномочий получает отказ, данные не меняются.

Непроверяемая формулировка: «Система должна быть быстрой». Проверяемый вариант: «В заданном тестовом окружении при 1000 заявках 95-й процентиль времени ответа списка на серии из 100 последовательных измерений не превышает согласованного значения». Окружение, данные, метод измерения и результат записываются; это не характеристика любой будущей промышленной нагрузки.

4.4. Модели, которые действительно нужны

Диаграмма вариантов использования, DFD и подробная диаграмма компонентов добавляются, когда уточняют задачу либо прямо требуются лабораторной. Не нужно дублировать один смысл во всех известных нотациях. Для каждой схемы в тексте укажите ее назначение, объясните ключевое решение и сошлитесь на рисунок.

Храните редактируемый исходник PlantUML, Mermaid или draw.io вместе с экспортом SVG/PNG/PDF. Перед сдачей проверьте, что исходник действительно открывается или собирается. Изображение, сгенерированное ИИ, не освобождает от проверки связей и обозначений.

4.5. Трассируемость

Трассируемость - возможность найти, где требование отражено в модели, реализовано в программе и проверено. Одно требование может иметь несколько тестов; один сервис может реализовывать несколько правил.

Имена классов в примере не являются готовой программой. В своей матрице указывайте реально существующие файлы и тесты. Не заполняйте графу «реализовано» до появления проверяемого результата.

5. Как лабораторные превращаются в курсовую

5.1. Проектная линия КИС

Ниже приведена предлагаемая примерная карта этапов.

5.2. Линия реализации PHP

Результаты следует переносить на индивидуальную предметную область, а не создавать второй отдельный BizFlow параллельно курсовому проекту.

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

6. Структура пояснительной записки

6.1. Рекомендуемое оглавление

Введение

1. Анализ предметной области и постановка задачи автоматизации

1.1. Раскрытие предметной области и(или) идей автоматизации, либо характеристика организации, процесса и информационных потоков.

1.2. Проблемы исходного процесса и анализ существующих решений. Конкурентный анализ.

1.3. Требования к системе и границы разрабатываемой версии.

2. Проектирование корпоративной веб-подсистемы или ресурса

2.1. Целевой бизнес-процесс, роли и пользовательские сценарии.

2.2. Проектирование данных и обеспечение их целостности. ERD-диаграмма.

2.3. Архитектура (монолит, микросервисы или др.), интерфейсы, безопасность и обоснование технологий.

3. Реализация, тестирование и оценка результата

3.1. Реализация серверной части и бизнес-логики на Symfony.

3.2. Реализация пользовательского интерфейса и взаимодействия с API.

3.3. Тестирование, развертывание и оценка результатов разработки.

Заключение. Список использованных источников. Приложения.

Заголовки уточняются под тему. Не называйте параграф «Теоретические основы PHP», если он должен объяснять проектное решение. Курсовая не является пересказом документации языка.

6.2. Объем и распределение материала

Предлагаемый ориентир для интегрированной работы: 30-40 страниц от введения до заключения включительно. Титульный лист, задание, содержание, список источников и приложения в этот объем не входят. Это локальный проектный ориентир.

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

В конце каждой главы сформулируйте вывод объемом примерно один абзац: какой результат получен и как он используется дальше. Вывод главы 1 должен подводить к проектированию, главы 2 - к реализации, главы 3 - к итоговой оценке.

7. Как написать введение и аналитическую главу (примерное содержимое)

7.1. Введение: от проблемы к проверяемой цели

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

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

Объект - процесс или деятельность, которую изучают: обработка внутренних сервисных заявок. Предмет - рассматриваемые в работе способы и средства автоматизации: модели, алгоритмы и программные средства учета, маршрутизации и контроля заявок. Не объявляйте предметом весь язык PHP.

Цель: «Спроектировать и разработать работоспособную веб-подсистему обработки сервисных заявок на PHP/Symfony и MySQL, обеспечивающую регистрацию, назначение исполнителя, контроль состояний и формирование отчетности». Проверяется существованием работающих функций и тестов, а не обещанием «повысить эффективность на 40 %» без измерений.

Задачи должны соответствовать действиям и результатам: исследовать процесс; сформировать требования; спроектировать данные и архитектуру; реализовать сервер и интерфейс; протестировать; подготовить развертывание и оценить ограничения. В заключении каждая задача получает конкретный ответ.

Методы выбираются по фактически выполненной работе: анализ документов, сравнение аналогов, моделирование процессов, объектно-ориентированное проектирование, функциональное тестирование, измерительный эксперимент. Не включайте опрос, машинное обучение или статистический анализ, если они не выполнялись.

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

7.2. Параграф 1.1: организация и исходный процесс

Опишите участников, их ответственность, входные и выходные документы, используемые средства и границы исследования. Добавьте AS-IS и небольшую таблицу информационных потоков. Для каждого потока укажите источник, получателя, состав данных, частоту и проблему обработки.

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

7.3. Параграф 1.2: проблема и аналоги

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

Для характеристик продуктов используйте документацию производителей и отмечайте дату проверки. «Не найдено в изученной документации» не равно «функции нет». Не превращайте отсутствие доступа к платной версии в отрицательную оценку продукта.

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

7.4. Параграф 1.3: постановка задачи

Включите согласованные FR, NFR, BR, приоритеты и критерии приемки. Опишите включенный и исключенный функционал. Приложите матрицу требований полностью, если она велика; в основном тексте объясните ключевые требования и причины их выбора.

Проверьте границы: при наличии слов «автоматическое распределение» нужен алгоритм распределения, а не ручной выбор в списке. «Контроль остатков» требует правил изменения количества. «Мониторинг сроков» требует определения срока, состояния просрочки и расчета показателя.

8. Как написать проектную главу

8.1. Параграф 2.1: целевой процесс и сценарии

Покажите TO-BE, роли, основные и альтернативные сценарии. Каждый сценарий описывается через участника, цель, предусловия, последовательность действий, исключения и постусловия.

Пример UC-02 «Назначение исполнителя». Участник - руководитель подразделения. Предусловия: руководитель вошел в систему, заявка относится к его подразделению и имеет состояние new. Основной результат: исполнитель сохранен, состояние assigned, запись истории создана. Альтернатива: заявка уже изменена другим пользователем; система сообщает конфликт и не перезаписывает изменения молча.

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

8.2. Параграф 2.2: данные

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

Пример: у заявки есть автор, категория, подразделение и необязательный исполнитель; у заявки может быть несколько комментариев и вложений. Удаление категории, используемой в заявках, запрещается либо заменяется архивированием. Выбранное правило должно одинаково работать в интерфейсе и API.

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

Важные индексы обосновываются запросами: поиск по статусу и дате, фильтрация по подразделению. При измерении производительности сохраняйте план запроса, объем данных и методику. Само наличие индекса не доказывает ускорение любого запроса.

8.3. Параграф 2.3: архитектура и контракты

Опишите состав приложения и путь запроса: браузер - маршрут - контроллер - проверка полномочий - прикладной сервис - репозиторий/ORM - MySQL - ответ. Для HTML-страницы добавляется Twig, для JSON - согласованная сериализация. Рядом с диаграммой объясните, где размещена бизнес-логика и почему.

В сравнении вариантов достаточно критериев, важных для проекта: сложность реализации, независимость модулей, развертывание, тестирование и возможное развитие. Выбор монолита должен опираться на ограниченный объем задачи и доступные ресурсы, а не на утверждение, что микросервисы «плохие» или «всегда быстрее».

Для API определите ресурс, метод, URL, поля запроса, успешный ответ, возможные ошибки, права и критерий проверки. OpenAPI должен соответствовать реально работающим операциям. Указывайте версию спецификации; не называйте Swagger UI отдельной реализацией сервера.

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

9. Как описать реализацию

9.1. Серверная часть

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

Разберите один содержательный алгоритм: расчет стоимости, назначение ресурса, проверку допустимости перехода, определение просрочки. Укажите входы, выходы, ограничения и ошибки. В основном тексте достаточно короткого ключевого фрагмента; полный исходный код передается электронно.

Для взаимосвязанных изменений объясните транзакционную границу. Например, смена исполнителя, состояния и истории должна рассматриваться как единая операция. При риске конкурентных изменений определите способ обнаружения конфликта; последовательное выполнение двух запросов одним пользователем не доказывает корректность конкурентного сценария. Механизмы транзакций и блокировок выбираются с учетом документации Doctrine.

Денежные значения храните и рассчитывайте по согласованной точной модели: целые минимальные единицы валюты или DECIMAL с подходящей обработкой. Запишите валюту, округление и граничные случаи. Не заявляйте финансовую точность, опираясь на произвольные вычисления float.

9.2. Интерфейс и AJAX

Покажите основные пользовательские страницы: список с фильтрами, карточку объекта, форму, действие изменения состояния и отчет. Скриншот сопровождайте пояснением сценария и результата. Он должен содержать безопасные демонстрационные данные.

Сначала обеспечьте корректную обычную форму и серверную валидацию. Затем добавьте клиентские подсказки, DOM-события и асинхронный сценарий. При fetch показывайте состояние загрузки, блокируйте случайную повторную отправку, обрабатывайте отсутствие данных, ошибку и успех. HTTP-ошибка не всегда вызывает отклонение Promise: проверяйте response.ok или статус.

Для демонстрации AJAX нужны как минимум получение данных и одно изменяющее действие. Проверяющий должен увидеть реальный запрос в Network, ответ сервера и изменение страницы. Подмена результатов заранее подготовленным массивом JavaScript не засчитывается как взаимодействие с API.

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

9.3. Безопасность как проверяемый результат

Аутентификация устанавливает пользователя; авторизация определяет допустимые действия. В Symfony используйте штатное хеширование паролей и согласованные средства контроля доступа. Проверяйте полномочия на сервере, включая доступ к отдельным объектам.

Серверная валидация обязательна независимо от JavaScript. Для сессионной аутентификации опишите защиту изменяющих запросов от CSRF, в том числе при отправке JSON: защита Symfony Forms не означает автоматической защиты произвольного API-контроллера .

В шаблонах сохраняйте экранирование пользовательских значений. В JavaScript добавляйте обычный пользовательский текст через textContent, а не интерпретацию HTML; небезопасное использование raw/innerHTML требует отдельного обоснования и защиты . Не храните реальные пароли, ключи и персональные данные в репозитории.

При загрузке файлов ограничивайте размер и допустимые типы, формируйте безопасное серверное имя и проверяйте доступ к скачиванию/удалению. Исходное имя файла клиента не считается доверенным. Загруженный файл не должен становиться исполняемым скриптом. Если по заданию используется Flysystem, он не заменяет проверку содержимого и полномочий.

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

10. Тестирование и доказательство работоспособности

10.1. Что проверяется автоматически

В опубликованной итоговой лабораторной PHP установлен минимум: 3 модульных, 3 интеграционных и 3 функциональных/API-тестов.

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

Набор параметров с одинаковой проверкой сам по себе не доказывает широту покрытия. Названия тестов должны объяснять проверяемое поведение. Количество не освобождает от проверки двух основных бизнес-сценариев и всех критичных ограничений.

10.2. Тестовые данные и окружение (вариативно)

Используйте отдельную тестовую базу, отличную от базы демонстрации и реальной эксплуатации. Symfony предусматривает отдельные настройки test; тесты не должны повреждать рабочие данные. Учетная запись тестовой БД по возможности не получает доступа к другим базам.

Подготовьте воспроизводимые фикстуры: пользователи всех ролей, объекты нескольких подразделений, основные состояния и граничные случаи. Не делайте тесты зависимыми от ручного редактирования базы перед запуском. Случайные данные должны иметь контролируемую генерацию, если они влияют на повторяемость.

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

10.3. Браузерная и приемочная проверка

Обычный тестовый HTTP-клиент Symfony не является полноценным браузером с исполнением JavaScript. Поэтому успешные серверные тесты не доказывают работоспособность AJAX-интерфейса. Проведите ручные браузерные проверки; автоматизацию настоящего браузера можно добавить отдельно (по желанию).

Минимальный ручной набор: пройти оба основных процесса; проверить интерфейс для каждой роли; выполнить AJAX-чтение и изменение; воспроизвести ошибку сервера или сети; открыть узкий экран; проверить загрузку и удаление вложения. Отметьте фактический результат и приложите доказательство при необходимости.

10.4. Как писать вывод о качестве

Корректно: «На версии v1.0 выполнено 40 автоматизированных проверок и 8 ручных сценариев. Обнаруженные дефекты перечислены в таблице. Не проверялась работа при одновременной нагрузке более указанной в эксперименте». Некорректно: «Система полностью безопасна и выдерживает любую нагрузку».

Если тесты не пройдены, укажите ошибки и их влияние. Пропущенный тест не считается успешным. ИИ может предложить тесты и помочь анализировать журнал, но не заменяет реальный запуск.

11. Развертывание и электронное приложение

11.1. Что означает воспроизводимый запуск

Студент демонстрирует исходный код и может установить зависимости, настроить окружение, создать структуру MySQL, загрузить безопасные демонстрационные данные и открыть приложение. Для локальной демонстрации допустим Symfony CLI либо заранее подготовленная конфигурация Docker Compose.

11.2. Структура передаваемого проекта (примерная)

project/

README.md

composer.json

composer.lock

symfony.lock

.env.example

config/

src/

templates/

assets/

public/

migrations/

tests/

docs/

project-passport.md

requirements.md

traceability.md

architecture/

api/openapi.yaml

api/postman/

testing/test-report.md

deployment.md

user-guide.md

ai-usage.md

submission-manifest.md

report/

coursework.pdf

Структура ориентировочная: не создавайте пустые папки и файлы ради соответствия дереву. Например, файл OpenAPI может иметь расширение JSON. Если symfony.lock не используется в выбранной конфигурации, объясните это; не добавляйте фиктивный lock-файл.

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

11.3. Что обязательно написать в README

Название и назначение; поддерживаемые версии; системные требования и расширения PHP; установка зависимостей; настройка переменных; создание БД и миграции; создание демонстрационных учетных записей; загрузка тестовых данных; подготовка ресурсов; запуск; URL приложения и API-документации; запуск тестов; резервное копирование учебных данных; известные ограничения.

Команды проверяются с нуля. Для Composer используется установка по lock-файлу, а не бесконтрольное обновление всех зависимостей. Порядок запуска тестов отделяется от production-установки без dev-зависимостей. Нельзя сначала исключить PHPUnit из установки, а затем обещать запуск тестов без дополнительного шага.

Демонстрационные учетные записи не должны давать доступ к реальной организации. Пароль локального учебного стенда можно задать при развертывании; для публичного стенда передавайте проверяющему доступ отдельно. Не публикуйте действующий пароль администратора реального сервера в открытом README.

12. Оформление, источники и академическая добросовестность (если нет приказа с иными требованиями)

12.1. Рабочий профиль оформления

Объем 30-40 страниц основного текста.

Основной текст не размещайте в текстовых полях и картинках. Используйте подписи и перекрестные ссылки редактора. Перед отправкой PDF проверьте таблицы, формулы, переносы, содержание и читаемость схем.

Большую ERD размещайте на отдельной странице или в приложении; не уменьшайте ее до нечитаемых надписей.

12.2. Как оформлять иллюстрации и листинги

В тексте сначала поясните, зачем приведена схема, затем дайте ссылку: «Связи заявок и исполнителей представлены на рисунке 2.2». Под рисунком: «Рисунок 2.2 - Модель данных подсистемы». Над таблицей: «Таблица 3.1 - Результаты проверки требований».

У авторских схем укажите «Составлено автором». Если схема переработана, укажите источник и характер переработки. Скриншоты собственного приложения не являются доказательством чужого опубликованного утверждения.

Короткий листинг должен сопровождаться назначением, местом в проекте и объяснением ключевого решения. Не вставляйте код снимком экрана, если он нужен для чтения. Весь код системы хранится в электронном приложении, а не в десятках страниц печатного листинга.

12.3. Источники и ссылки

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

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

В этом профиле предлагаются ссылки вида [5] и [5, с. 18], согласованные с нумерованным списком. Если подразделение требует подстрочные сноски, используется его порядок. Не смешивайте два формата случайным образом. В старых вузовских документах встречаются ссылки на старые редакции стандартов; номера из них не переносятся автоматически как доказательство текущих требований.

Пример электронного источника: «Symfony. Testing. Документация Symfony 7.4. URL: https://symfony.com/doc/7.4/testing.html (дата обращения: 20.09.2026)». Для вашей работы дата должна быть фактической, а не автоматически скопированной из пособия.

13. Резервный перечень из 45 тем

Собственная согласованная тема предпочтительнее. Перечень ниже предназначен для выбора, когда подходящая задача пока не найдена. Все темы предполагают проектирование и реализацию на PHP/Symfony и MySQL, роли пользователей, корпоративный процесс, API, отчетность и требования раздела 3. Можно выбрать иной стек по согласованию с руководителем.

Название можно уточнить под организацию. Для каждой темы указано предметное ядро и отличительное правило, чтобы работа не сводилась к одинаковому CRUD с замененными названиями. Приведенные правила и показатели - задания для проектирования, а не утверждения о реально существующих организациях.
Номер темы соответствует номеру в журнале.

13.1. Продажи и работа с клиентами

1. Веб-подсистема управления обращениями и сделками отдела продаж. Ядро: клиент, обращение, сделка, этап, ответственный. Правило: закрытие сделки требует результата и причины отказа или суммы. Отчет: конверсия между этапами без необоснованного сравнения разных когорт.

2. Веб-подсистема подготовки и согласования коммерческих предложений. Ядро: контрагент, предложение, позиции, версия, согласование. Правило: отправлять клиенту можно только согласованную версию. Отчет: сроки согласования и суммы предложений.

3. Веб-подсистема обработки заказов корпоративных клиентов. Ядро: заказ, позиции, каталог, клиент, исполнение. Правило: подтверждение заказа возможно только после проверки обязательных условий. Отчет: портфель и динамика статусов заказов.

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

5. Веб-подсистема обработки рекламаций и претензий клиентов. Ядро: заказ, рекламация, причина, ответственный, решение. Правило: закрытие требует зафиксированного решения. Отчет: причины и длительность обработки рекламаций.

13.2. Закупки и поставщики

6. Веб-подсистема согласования внутренних заявок на закупку. Ядро: подразделение, заявка, позиции, категория, согласование. Правило: автор не согласует собственную заявку. Отчет: очередь согласования и суммы по подразделениям.

7. Веб-подсистема сбора и сравнения предложений поставщиков. Ядро: запрос, поставщик, предложение, позиции, критерии. Правило: сравниваются предложения с согласованными единицами и валютой. Отчет: сравнительная ведомость с раскрытыми весами критериев.

8. Веб-подсистема учета заказов поставщикам и частичных поставок. Ядро: поставщик, заказ, позиция, поставка, приемка. Правило: принятый объем не превышает согласованный объем с учетом допустимого отклонения. Отчет: недопоставки и сроки.

9. Веб-подсистема оценки исполнения обязательств поставщиками. Ядро: поставщик, обязательство, поставка, несоответствие, оценка. Правило: оценка вычисляется из зарегистрированных событий, а не вводится произвольно. Отчет: показатели своевременности и качества.

10. Веб-подсистема управления каталогом внутренних потребностей организации. Ядро: подразделение, потребность, категория, период, план закупки. Правило: однотипные потребности объединяются без потери заявителя и количества. Отчет: консолидированная потребность по периодам.

13.3. Склад, имущество и ресурсы

11. Веб-подсистема выдачи и возврата оборудования сотрудникам. Ядро: оборудование, сотрудник, выдача, возврат, состояние. Правило: одновременно допускается только одна открытая выдача экземпляра. Отчет: имущество у сотрудников и просроченные возвраты.

12. Веб-подсистема учета расходных материалов подразделений. Ядро: материал, склад, поступление, расход, заявка. Правило: проведение расхода не создает отрицательный остаток. Отчет: остатки и потребление по подразделениям.

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

14. Веб-подсистема бронирования общих помещений и оборудования. Ядро: ресурс, интервал, бронирование, сотрудник, ограничение. Правило: подтвержденные интервалы одного ресурса не пересекаются. Отчет: загрузка и отмены.

15. Веб-подсистема перемещения материальных ресурсов между подразделениями. Ядро: ресурс, подразделение-отправитель, получатель, перемещение, приемка. Правило: передача завершается подтверждением получателя. Отчет: ресурсы в пути и длительность перемещений.

15.4. Кадровые процессы и обучение

16. Веб-подсистема адаптации новых сотрудников. Ядро: сотрудник, план адаптации, задача, наставник, результат. Правило: этап завершается только при выполнении обязательных задач. Отчет: прогресс адаптации и просрочки.

17. Веб-подсистема согласования отпусков и отсутствий сотрудников. Ядро: сотрудник, подразделение, заявление, период, согласование. Правило: заявитель не утверждает свое заявление; пересечения проверяются по заданным правилам. Отчет: план отсутствий. Расчет кадровых выплат не входит в базовый объем.

18. Веб-подсистема планирования внутреннего обучения персонала. Ядро: курс, сотрудник, заявка, учебная группа, результат. Правило: зачисление учитывает вместимость группы. Отчет: прохождение обучения и распределение потребностей.

19. Веб-подсистема учета допусков и сроков действия квалификаций сотрудников. Ядро: сотрудник, квалификация, подтверждение, срок, требование рабочего места. Правило: просроченное подтверждение не считается действующим. Отчет: истекающие сроки. Проект не заменяет официальную процедуру допуска.

20. Веб-подсистема организации наставничества сотрудников. Ядро: наставник, участник, программа, встреча, задача. Правило: назначение учитывает заданную предельную нагрузку наставника. Отчет: выполнение планов и занятость наставников.

13.5. Документы и внутренний контроль

21. Веб-подсистема согласования внутренних документов. Ядро: документ, версия, маршрут, участник, решение. Правило: изменение содержания после согласования создает новую версию. Отчет: документы на согласовании и время прохождения.

22. Веб-подсистема контроля поручений руководителя. Ядро: поручение, исполнитель, срок, подзадача, отчет о выполнении. Правило: исполнение и приемка разделены по ролям. Отчет: просроченные поручения и загрузка исполнителей.

23. Веб-подсистема управления корпоративной базой знаний. Ядро: статья, категория, версия, редактор, публикация. Правило: публикация требует проверки редактором. Отчет: актуальность материалов и очередь обновления.

24. Веб-подсистема ознакомления сотрудников с внутренними регламентами. Ядро: регламент, версия, сотрудник, назначение, подтверждение. Правило: новая версия требует нового подтверждения ознакомления. Отчет: выполнение обязательных ознакомлений.

25. Веб-подсистема учета несоответствий и корректирующих мероприятий. Ядро: проверка, несоответствие, мероприятие, ответственный, подтверждение. Правило: закрытие несоответствия требует проверки результата мероприятия. Отчет: повторные причины и просроченные меры.

13.6. ИТ-служба и сопровождение систем

26. Веб-подсистема регистрации и обработки заявок в ИТ-службу. Ядро: заявка, категория, приоритет, назначение, комментарий. Правило: завершение и приемка отделены; переходы проверяются сервером. Отчет: сроки и незавершенные заявки.

27. Веб-подсистема учета ИТ-активов и программных лицензий. Ядро: устройство, программный продукт, лицензия, назначение, сотрудник. Правило: число активных назначений не превышает разрешенное количество. Отчет: использование лицензий и сроки продления.

28. Веб-подсистема согласования изменений корпоративных приложений. Ядро: запрос на изменение, система, риск, согласование, выпуск. Правило: включение в выпуск возможно после согласования. Отчет: изменения по системам и причины переноса.

29. Веб-подсистема учета инцидентов и повторяющихся проблем ИТ-инфраструктуры. Ядро: инцидент, сервис, проблема, решение, событие. Правило: повторные инциденты связываются с проблемой без удаления истории. Отчет: повторяемость и длительность восстановления по учебным данным.

30. Веб-подсистема планирования регламентного обслуживания ИТ-оборудования. Ядро: оборудование, регламент, план, работа, исполнитель. Правило: следующая дата обслуживания вычисляется по согласованному правилу. Отчет: плановые и просроченные работы.

13.7. Производственные и технические процессы

31. Веб-подсистема учета производственных заданий небольшого цеха. Ядро: заказ, задание, операция, рабочее место, результат. Правило: следующий этап доступен после завершения обязательного предыдущего. Отчет: готовность заданий и незавершенное производство.

32. Веб-подсистема регистрации контроля качества продукции. Ядро: партия, проверка, показатель, дефект, решение. Правило: решение о приемке зависит от введенных результатов по учебной спецификации. Отчет: доля несоответствий. Автоматическое управление оборудованием не требуется.

33. Веб-подсистема учета заявок на ремонт производственного оборудования. Ядро: оборудование, заявка, диагностика, работа, использованный материал. Правило: возврат в эксплуатацию требует зафиксированного результата ремонта. Отчет: затраты и время простоя.

34. Веб-подсистема планирования технического обслуживания автопарка организации. Ядро: транспортное средство, пробег, регламент, обслуживание, работа. Правило: необходимость обслуживания определяется датой или пробегом. Отчет: ближайшие и просроченные работы. Маршрутная оптимизация не обязательна.

35. Веб-подсистема учета инструментов и проверки их готовности к использованию. Ядро: инструмент, проверка, срок, выдача, состояние. Правило: инструмент с истекшей проверкой не выдается без предусмотренного решения. Отчет: доступность и сроки проверок.

13.8. Организации сферы услуг

36. Веб-подсистема управления заказами сервисного центра. Ядро: клиент, устройство, заказ, диагностика, работа. Правило: выполнение платных работ начинается после согласования сметы. Отчет: этапы заказов и загрузка мастеров.

37. Веб-подсистема планирования проектов и задач небольшой студии разработки. Ядро: заказчик, проект, задача, исполнитель, трудозатраты. Правило: закрытие проекта требует приемки обязательных задач. Отчет: плановые и фактические трудозатраты без имитации реальных измерений.

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

39. Веб-подсистема учета заказов типографии. Ядро: заказ, макет, версия, технологическая операция, материал. Правило: запуск производства использует согласованную версию макета. Отчет: готовность заказов и использование материалов.

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

13.9. Образовательные и научные организации

41. Веб-подсистема бронирования и выдачи оборудования учебной лаборатории. Ядро: оборудование, занятие, бронирование, выдача, возврат. Правило: подтверждение учитывает доступность и техническую готовность. Отчет: загрузка оборудования и задолженности по возврату.

42. Веб-подсистема учета заявок на проведение учебных мероприятий. Ядро: мероприятие, организатор, аудитория, ресурс, согласование. Правило: ресурс закрепляется только после проверки конфликтов. Отчет: календарь и потребность в ресурсах.

43. Веб-подсистема сопровождения заявок на участие в научных конференциях. Ядро: участник, мероприятие, заявка, документы, согласование. Правило: отправка на согласование требует комплектности документов. Отчет: состояния заявок и сроки. Финансирование рассчитывается только по учебным правилам.

44. Веб-подсистема распределения и контроля выполнения учебных проектов. Ядро: тема, студент, руководитель, этап, результат. Правило: приемка этапа выполняется уполномоченным руководителем. Отчет: прогресс и невыполненные этапы. Она не подменяет официальную образовательную систему.

45. Веб-подсистема учета заявок на обслуживание помещений и оборудования кафедры. Ядро: помещение, оборудование, заявка, исполнитель, работа. Правило: заявитель видит собственные обращения, ответственные - назначенные объекты. Отчет: состояние обращений и частота повторных неисправностей.

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

14. Профессиональные роли в одном учебном проекте

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

Источники и основания пособия

Дата проверки веб-источников: 20.09.2026. Для вузовских документов указана область применения; их наличие в открытом доступе не подтверждает автоматическую применимость к любой образовательной программе. Страницы-каталоги [10, 11] приведены как заданная основа интеграции, с ограничением доступа к текстам заданий, описанным в примечании преподавателю.

[1] РУДН. Юридический институт. Методические рекомендации по выполнению курсовых работ. Без указанного года в доступном документе. Открыть документ.

[2] РУДН. Кафедра международного права. Требования к оформлению курсовых работ. Без указанного года в доступном документе. Открыть документ.

[3] Милованов Д.М., Хасаншин И.Я. Методические материалы по выполнению курсовой работы по дисциплине «Современные технологии программирования». Финансовый университет, 2021. Открытая копия на стороннем сервисе, не подтвержденная текущая редакция. Просмотреть копию.

[4] Морозова Ю.В. Объектно-ориентированное программирование: методические указания к выполнению курсовой работы. Томск: ТУСУР, 2018. 15 с. Карточка и содержание.

[5] МФ МГТУ им. Н.Э. Баумана. Кафедра К3. Требования по оформлению пояснительной записки к курсовой работе по дисциплине «Теория автоматов». Открыть страницу.

[6] Румянцев С.А. Лабораторные работы: общий стек и сквозной проект BizFlow. Открыть материал.

[7] Румянцев С.А. Разработка веб-приложений (PHP): опубликованные лабораторные I-XII. Названия этапов сверены по перечню ссылок практикума. Раздел курса.

[8] Румянцев С.А. Лабораторная работа XII. Итоговый проект BizFlow. Открыть задание.

[9] РУДН. Рабочая программа дисциплины «Разработка веб-приложений (PHP)», 38.03.05 «Бизнес-информатика», профиль «Разработка прикладных решений для бизнеса». 2026. Файл предоставлен преподавателем: Prog_РазВПP_38.03.05_РПРДБ_2026(1) (1).pdf. Использован для проверки границ применимости, а не как учебный план 09.03.03.

[10] Румянцев С.А. Корпоративные информационные системы (КИС), 2026. Каталог курса.

[11] Румянцев С.А. Проектирование систем электронных коммуникаций. Каталог курса.

[12] Румянцев С.А. Лабораторная работа 4. Варианты архитектуры ИС: монолит и микросервисы с тонким и толстым клиентом. Отдельный раздел «Проектирование архитектуры информационных систем». Открыть задание.

[13] Румянцев С.А. Лабораторная работа 5. API монолита и Postman. Отдельный раздел «Проектирование архитектуры информационных систем». Открыть задание.

[14] Symfony. Symfony 7.4 Release. Требования и сроки поддержки. Официальная страница.

[15] MySQL. MySQL 8.0 Reference Manual, A.1 MySQL FAQ: General. Сведения о начале серии MySQL 8.4 LTS. Официальная документация.

[16] Symfony. Testing. Документация 7.4. Открыть.

[17] Symfony. How to Implement CSRF Protection. Документация 7.4. Открыть.

[18] MDN Web Docs. Using the Fetch API. Открыть.

[19] Symfony. How to Deploy a Symfony Application. Документация 7.4. Открыть.

[20] Doctrine ORM. Transactions and Concurrency. Официальная документация.

[21] Symfony. Security. Документация 7.4. Открыть.

[22] Twig. Twig for Developers. Документация 3.x. Открыть.

[23] MDN Web Docs. Node: textContent property. Открыть.

[24] Symfony. How to Upload Files. Документация 7.4. Открыть.

[25] Symfony. AssetMapper: Simple, Modern CSS & JS Management. Документация 7.4. Открыть.

[26] Symfony. Installing & Setting up the Symfony Framework. Документация 7.4. Открыть.

[27] PHP Manual. Floating-point numbers. Официальная документация.