Индивидуальный предприниматель Жуков Дмитрий Михайлович
Платформа управления данными, ИИ агентами и отчетами (ПУДАО)
Документация, содержащая описание процессов,
обеспечивающих поддержание жизненного цикла программного обеспечения, в том числе устранение неисправностей и совершенствование, а также информацию о персонале, необходимом для обеспечения такой поддержки
Свидетельство о государственной регистрации программы для ЭВМ
№ 2026686541 от 01 сентября 2026 г.
Версия программного обеспечения 4.0.1
Редакция документа от 23.09.2026
Содержание
1. Общие сведения
2. Модель жизненного цикла
3. Организация разработки
4. Контроль качества и тестирование
5. Выпуск версий и развёртывание
6. Устранение неисправностей
7. Совершенствование программного обеспечения
8. Мониторинг эксплуатации
9. Резервное копирование и восстановление
10.Информация о персонале
11.Обучение пользователей и передача знаний
12.Порядок оказания технической поддержки
1. Общие сведения
Настоящий документ описывает процессы, которыми правообладатель обеспечивает поддержание жизненного цикла программного обеспечения Платформа управления данными, ИИ агентами и отчетами «ПУДАО» разработку, контроль качества, выпуск версий, устранение неисправностей, выявленных в ходе эксплуатации, совершенствование программного обеспечения, а также состав и квалификацию персонала, необходимого для обеспечения такой поддержки.
Поддержку жизненного цикла осуществляет правообладатель — ИП ЖУКОВ ДМИТРИЙ МИХАЙЛОВИЧ, Разработка, техническая поддержка и хранение исходных текстов осуществляются на территории Российской Федерации.
2. Модель жизненного цикла
Применяется итеративная модель с выпуском версий, привязанных к циклам эксплуатации у заказчика. Цикл эксплуатации Системы имеет выраженную сезонность: период активной работы пользователей, когда изменения в продуктивной среде сведены к устранению неисправностей, и межсезонье, когда выполняются доработки и переход на следующую версию.
┌────────────────┐ ┌────────────────┐ ┌──────────────┐ ┌───────────────┐
│ Сбор и анализ │──►│ Разработка │──►│ Тестирование │──►│ Выпуск версии │
│ требований │ │ │ │ и приёмка │ │ и развёртыв. │
└────────────────┘ └────────────────┘ └──────────────┘ └───────┬───────┘
▲ │
│ ▼
┌────────┴───────┐ ┌────────────────┐ ┌──────────────┐ ┌───────────────┐
│ Совершенствов. │◄──│ Анализ обращен.│◄──│ Поддержка │◄──│ Эксплуатация │
│ (бэклог цикла) │ │ и инцидентов │ │ пользователей│ │ │
└────────────────┘ └────────────────┘ └──────────────┘ └───────────────┘
│
▼
┌────────────────────────┐
│ Устранение неисправн. │──► внеплановый выпуск
└────────────────────────┘
Стадия | Содержание | Ответственный |
Сбор и анализ требований | Обращения пользователей, изменения регламента заказчика, замечания по итогам цикла эксплуатации. Формирование бэклога на следующую версию | Аналитик, руководитель проекта |
Разработка | Реализация задач бэклога в отдельных ветках, взаимная проверка кода | Разработчики, технический руководитель |
Тестирование и приёмка | Автоматические проверки, приёмочные сценарии, повторный прогон на данных предыдущего цикла | Инженер по тестированию |
Выпуск версии | Сборка, применение миграций, развёртывание, проверка после выката | Инженер по эксплуатации |
Эксплуатация и поддержка | Приём обращений, консультирование, мониторинг, резервное копирование | Служба поддержки |
Устранение неисправностей | Диагностика, исправление, регрессионная проверка, внеплановый выпуск | Разработчики, служба поддержки |
Снятие с поддержки | Уведомление заказчиков, выгрузка данных, передача архива | Руководитель проекта |
3. Организация разработки
3.1. Управление исходными текстами
· Исходные тексты хранятся в системе управления версиями на российской площадке — [ХОСТИНГ РЕПОЗИТОРИЯ]. Доступ — по индивидуальным ключам, с разграничением прав.
· Ветвление привязано к циклам эксплуатации: на каждый цикл заводится ветка разработки, отпочкованная от версии, отработавшей предыдущий цикл. Это позволяет одновременно сопровождать версию в эксплуатации и разрабатывать следующую.
· Каждая задача выполняется в отдельной ветке и вливается после проверки. Изменение попадает в основную ветку только вместе с описанием способа проверки.
· Реквизиты доступа (пароли, ключи, токены) в систему управления версиями не помещаются; в репозитории хранятся только образцы файлов конфигурации.
· Сопроводительная документация ведётся в том же репозитории и изменяется вместе с кодом.
3.2. Среды
Среда | Назначение | Данные |
Локальная | Разработка и отладка. Разворачивается из одного описания контура одной командой | Обезличенная копия либо демонстрационный набор |
Тестовая | Проверка изменений до выката, демонстрация заказчику | Обезличенная копия продуктивной базы; исходящие уведомления отключены |
Контур повторного прогона | Воспроизведение полного цикла эксплуатации предыдущего периода на новой версии кода — проверка того, что доработки не сломали сложившийся процесс | Копия данных завершённого цикла |
Продуктивная | Промышленная эксплуатация | Рабочие данные заказчика |
Изоляция тестовых сред обязательна. На всех непродуктивных контурах отправка исходящих уведомлений отключается общим параметром конфигурации. Это исключает рассылку писем и сообщений реальным пользователям при отладке — типовой источник инцидентов при работе с копией продуктивных данных. | ||
3.3. Нумерация и планирование версий
· Версия имеет вид «основная.дополнительная.исправление» и хранится в одном месте конфигурации. Номер версии попадает в каждую запись журнала событий: без него невозможно установить, на какой сборке произошёл сбой.
· Основная версия меняется при изменении модели данных или состава функций, дополнительная — при добавлении функций без нарушения совместимости, исправление — при устранении неисправностей.
· Плановые версии выпускаются в межсезонье, внеплановые — по мере устранения неисправностей высокого и критического уровня.
4. Контроль качества и тестирование
4.1. Виды проверок
Вид | Содержание | Когда выполняется |
Модульные и функциональные тесты | Проверка отдельных компонентов и обработчиков запросов | При каждом изменении |
Сквозные сценарии | Автоматизированное воспроизведение действий пользователя в браузере по каждой роли: подача заявки, проверка, возврат на доработку, повторная подача, оценка экспертом, работа рабочей группы, версии заявки, журнал событий | Перед выпуском версии |
Приёмочные сценарии | Ручное прохождение по плану тестирования с фиксацией ожидаемого результата на каждом шаге для каждой роли | Перед выпуском версии |
Повторный прогон цикла | Воспроизведение завершённого цикла эксплуатации на новой версии кода на контуре-двойнике | Перед крупными изменениями |
Проверка после развёртывания | Сокращённый набор проверок в продуктивной среде непосредственно после выката | После каждого выпуска |
4.2. Правила, обязательные к соблюдению
1. Задача без описания способа проверки в работу не берётся. В постановке задачи обязателен раздел «как проверяем»: что делаем и что обязаны увидеть на каждом шаге.
2. На каждую исправленную неисправность заводится регрессионный сценарий с указанием обстоятельств: затронутый файл, маршрут, роль пользователя, когда и как проявлялась. Без этих сведений сценарий со временем невозможно отличить от произвольного.
3. Ожидаемый результат не подгоняется под фактическое поведение системы. Если обнаружено расхождение с требованиями, сценарий фиксирует требуемое поведение и остаётся непройденным до устранения расхождения.
4. Найденный недостаток разграничения доступа оформляется отдельным негативным сценарием, ожидаемый результат которого описывает требуемое поведение.
5. План тестирования пополняется вместе с изменением, а не после него. Изменение считается завершённым, когда сценарии приведены в соответствие с кодом.
6. Реквизиты тестовых учётных записей в план тестирования не выносятся; указывается только путь к защищённому месту их хранения.
5. Выпуск версий и развёртывание
5.1. Порядок выпуска
1. Формирование состава версии из выполненных и проверенных задач.
2. Прогон полного набора автоматических проверок и приёмочных сценариев на тестовой среде.
3. Резервное копирование продуктивной базы данных и пользовательских файлов.
4. Развёртывание файлов приложения.
5. Применение миграций схемы базы данных.
6. Сброс кэша приложения.
7. Проверка работоспособности по сокращённому чек-листу.
8. Уведомление заказчика о выпуске с перечнем изменений.
5.2. Порядок отката
Откат выполняется при выявлении неустранимого в течение установленного времени нарушения работоспособности после выката:
1. Возврат файлов приложения к предыдущей версии.
2. При необходимости — откат миграций либо восстановление базы из резервной копии, созданной перед выкатом.
3. Проверка работоспособности, уведомление заказчика.
4. Разбор причины и оформление регрессионного сценария до повторной попытки выката.
Требование к продуктивной среде. Изменения в продуктивной среде вносятся только через выпуск версии. Правка файлов непосредственно на продуктивном сервере запрещена: она создаёт расхождение между эксплуатируемой версией и исходными текстами, после чего следующий выпуск затирает такую правку без предупреждения. Если внеплановое вмешательство было выполнено, оно подлежит немедленному переносу в исходные тексты и фиксации в журнале изменений. |
6. Устранение неисправностей
6.1. Каналы приёма обращений
Канал | Реквизиты | Режим |
Электронная почта | info@1212.pro | круглосуточно, обработка в рабочее время |
|
| рабочие дни, 9.00-18.00 (МСК) |
Каждое обращение регистрируется с присвоением номера. Заявителю сообщается номер, по которому он может получить сведения о состоянии обработки.
6.2. Классификация обращений и сроки
Уровень | Признаки | Реакция | Временное решение | Устранение |
Критический | Система недоступна пользователям; невозможна подача или проверка заявок; риск потери или искажения данных | 1 час в рабочее время | 4 часа | 1 рабочий день |
Высокий | Не работает существенная функция, обходного пути нет; затронута группа пользователей | 4 рабочих часа | 1 рабочий день | 3 рабочих дня |
Средний | Функция работает с ограничениями, обходной путь существует | 1 рабочий день | — | Ближайшее плановое обновление |
Низкий | Замечание к интерфейсу, неточность в тексте, предложение по удобству | 2 рабочих дня | — | По плану развития |
Приведённые сроки являются типовыми. Конкретные значения устанавливаются договором на техническую поддержку с заказчиком.
6.3. Порядок обработки
1. Регистрация. Обращение фиксируется с указанием заявителя, роли, времени, описания и приложенных материалов.
2. Классификация. Специалист поддержки определяет уровень по таблице 6.2 и проверяет, не является ли обращение вопросом по эксплуатации — такие обращения закрываются консультацией.
3. Диагностика. Обстоятельства воспроизводятся на тестовой среде. Основной источник сведений — журнал событий: по нему устанавливаются пользователь, время, действие, результат и версия приложения, на которой произошёл сбой.
4. Исправление. Изменение выполняется в отдельной ветке; одновременно оформляется регрессионный сценарий, воспроизводящий неисправность.
5. Проверка. Изменение проверяется на тестовой среде; регрессионный сценарий до исправления должен не проходить, после — проходить.
6. Выпуск. Для критического и высокого уровня — внеплановый выпуск, для остальных — включение в ближайшую плановую версию.
7. Закрытие. Заявитель уведомляется о результате. Обращение закрывается после подтверждения заявителем либо по истечении установленного срока ожидания.
6.4. Эскалация
Обращение передаётся на следующий уровень при невозможности решения в установленный срок:
Уровень | Кто | Что решает |
Первая линия | Специалист поддержки | Консультации по эксплуатации, восстановление доступа, типовые ситуации из перечня известных, регистрация обращений |
Вторая линия | Инженер по эксплуатации, аналитик | Диагностика с использованием журнала событий и логов, ошибки конфигурации, восстановление данных из версий, проблемы развёртывания |
Третья линия | Разработчики, технический руководитель | Дефекты программного обеспечения, требующие изменения кода или схемы данных |
Руководство проекта | Руководитель проекта | Нарушение сроков, спорные ситуации, привлечение дополнительных ресурсов |
7. Совершенствование программного обеспечения
7.1. Источники требований
· Обращения и предложения пользователей заказчика.
· Изменения нормативных требований и регламента процедуры.
· Итоги анализа цикла эксплуатации: узкие места, повторяющиеся обращения, данные журнала о фактическом использовании функций.
· Технический долг, зафиксированный при разработке.
· Требования информационной безопасности и обновление применяемых компонентов.
7.2. Порядок планирования
1. Требования вносятся в перечень задач цикла с указанием обоснования и способа проверки.
2. Задачи ранжируются по влиянию на процесс заказчика и по риску.
3. Состав версии согласуется с заказчиком до начала разработки.
4. Ход выполнения отражается в перечне задач; статус каждой задачи виден заказчику.
5. По завершении цикла проводится разбор итогов, результаты которого пополняют перечень принятых решений и перечень типовых ошибок, используемых при обучении новых сотрудников.
7.3. Направления развития
Направление | Содержание |
Обновление платформы | Перевод серверной части на актуальную версию среды исполнения; поддержка российских СУБД из единого реестра |
Совместимость с российскими ОС | Проведение испытаний и оформление протоколов совместимости с операционными системами из единого реестра |
Развитие конструктора | Расширение типов пунктов, правил проверки и вычисляемых значений |
Интеграционные возможности | Программный интерфейс для обмена данными с внешними информационными системами заказчика |
Интеллектуальная обработка документов | Предварительное заполнение пунктов по приложенным документам и контроль комплектности с применением моделей, исполняемых в контуре заказчика |
8. Мониторинг эксплуатации
· Журнал событий. Действия пользователей и системы фиксируются во внешнем сервисе, недоступном приложению на изменение. По журналу восстанавливается последовательность действий, приведшая к сбою.
· Аналитическая панель поверх журнала: активность пользователей, распределение событий и ошибок, версии приложения, неудачные попытки входа.
· Технические логи приложения и веб-сервера с раздельным накоплением ошибок и предупреждений.
· Контроль ресурсов узла: загрузка процессора, память, дисковое пространство, доступность сервисов-спутников.
· Плановая проверка состояния контура перед началом и по завершении периода активной эксплуатации.
9. Резервное копирование и восстановление
Объект | Периодичность | Порядок восстановления |
База данных | Ежесуточно, а также непосредственно перед каждым выпуском версии | Развёртывание копии из резервного файла с последующей проверкой целостности и работоспособности |
Документы заявок | Средствами объектного хранилища, с сохранением версий объектов | Восстановление объекта из хранилища |
Версии заявок | При каждом сохранении формы, с дублированием в объектное хранилище | Возврат заявки к выбранной версии средствами Системы |
Конфигурация этапов | Перед каждым изменением структуры | Восстановление предыдущей редакции средствами Системы |
Исходные тексты и конфигурация развёртывания | Постоянно, в системе управления версиями | Развёртывание версии из репозитория |
Пригодность резервных копий проверяется контрольным восстановлением на тестовой среде не реже одного раза в квартал. Копия, ни разу не восстановленная, резервной копией не считается.
10. Информация о персонале
Поддержание жизненного цикла обеспечивается штатными сотрудниками правообладателя. Состав, численность и квалификация приведены ниже.
Роль | Числ. | Квалификационные требования | Зона ответственности |
Руководитель проекта | 1 | Опыт руководства проектами разработки от 3 лет; знание предметной области заказчика | Планирование версий, согласование состава работ с заказчиком, контроль сроков, разрешение спорных ситуаций, эскалация |
Технический руководитель (архитектор) | 1 | Опыт разработки веб-приложений от 5 лет; проектирование архитектуры, модели данных и разграничения доступа | Архитектурные решения, проверка изменений, контроль технического долга, третья линия поддержки |
Разработчик серверной части | 1 | Профильная подготовка; опыт от 2 лет; PHP, каркас Yii 2, реляционные СУБД, SQL, миграции схемы | Реализация задач бэклога, устранение дефектов, миграции данных, консольные команды сопровождения |
Разработчик интерфейса | 1 | Опыт от 2 лет; HTML, CSS, JavaScript, шаблоны серверного отображения, адаптивная вёрстка | Экранные формы, конструктор этапов, печатные формы, доступность интерфейса |
Разработчик сервисов обработки данных | 1 | Опыт от 2 лет; Python, разработка сервисов с программным интерфейсом, работа с объектными хранилищами | Шлюз хранилища, приёмник журнала, сервис версий, панель аналитики |
Инженер по тестированию | 1 | Опыт от 2 лет; проектирование тестовых сценариев, автоматизация сквозных проверок в браузере | План тестирования, приёмка версий, регрессионные сценарии, повторный прогон цикла |
Аналитик | 1 | Высшее образование; опыт формализации требований от 2 лет; знание регламента процедур заказчика | Сбор и формализация требований, настройка конструктора этапов, инструкции пользователям, обучение |
Специалист технической поддержки | 1 | Среднее профессиональное либо высшее образование; знание функций Системы в объёме документации по эксплуатации; навык работы с системой учёта обращений | Первая линия: приём и регистрация обращений, консультирование, восстановление доступа, типовые ситуации |
Минимальный состав, достаточный для поддержания жизненного цикла — 8 человек: руководитель проекта (он же аналитик), технический руководитель, два разработчика, инженер по тестированию, инженер по эксплуатации, специалист поддержки. В период активной эксплуатации состав службы поддержки увеличивается пропорционально числу пользователей. Совмещение ролей допускается, за исключением совмещения разработки и приёмки одного и того же изменения. | |||
Поддержание квалификации. Новые сотрудники вводятся в проект по сопроводительной документации репозитория: описание архитектуры, перечень принятых решений с обоснованием и перечень типовых ошибок, накопленных при работе с реальными данными. Эти документы изменяются вместе с кодом и являются обязательными к прочтению перед правкой соответствующих подсистем.
11. Обучение пользователей и передача знаний
· Документация по эксплуатации для каждой роли передаётся заказчику в составе поставки.
· Проводится очное либо дистанционное обучение администраторов заказчика: управление пользователями и правами, конструктор этапов, справочники, отчётность.
· Для участников процедуры готовятся краткие инструкции по подаче и доработке заявки.
· Перед началом периода активной эксплуатации проводится консультационная сессия по изменениям текущей версии.
12. Порядок оказания технической поддержки
Параметр | Значение |
Организация, оказывающая поддержку | ИП «ЖУКОВ ДМИТРИЙ МИХАЙЛОВИЧ» |
Место оказания поддержки | Российская Федерация, Казань, Петербургская 52 |
Язык обращения | Русский |
Режим работы | Рабочие дни, 9.00-18.00 (МСК). В период активной эксплуатации — по согласованному с заказчиком расширенному графику |
Состав поддержки | Консультирование пользователей; устранение неисправностей; предоставление обновлений; помощь при развёртывании и обновлении; восстановление данных из резервных копий и версий |
Условия предоставления | По договору на техническую поддержку. Гарантийная поддержка предоставляется в течение срока, установленного договором поставки |
Снятие с поддержки | Заказчик уведомляется не менее чем за 6 месяцев. Обеспечивается выгрузка данных в машиночитаемом формате и передача архива документов |