Описание жизненного цикла

1. Общие сведения

Настоящий документ разработан в соответствии с ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств». Документ описывает процессы жизненного цикла программного комплекса «Reports Security Suite» (далее – RSS) применительно к деятельности организации-разработчика ООО «БИТ ПЛЮС» (далее – Организация) и содержит сведения о персонале, инфраструктуре поддержки.

2. Процессы жизненного цикла RSS

Процессы сгруппированы в соответствии с группами процессов ГОСТ Р ИСО/МЭК 12207-2010.

2.1. Процессы соглашения

2.1.1. Процесс поставки

Цель – организация и выполнение полного цикла поставки RSS.

В результате успешного осуществления процесса поставки:

● определяется объём лицензирования;

● согласовываются с заказчиком требования к аппаратному обеспечению (архитектура x86-64, объём оперативной памяти и дискового пространства), сетевой инфраструктуре и изолированным программно-аппаратным средам;

● при необходимости согласовываются параметры интеграции с внешними системами;

● результаты достигнутых договорённостей закрепляются в договорных документах между заказчиком и Организацией;

● Организация передаёт заказчику офлайн-архив, содержащий образы Docker, главный сценарий установки install.sh, файл описания контейнеров docker-compose.yml, исходный код ядра (core/), модуля интеграции (integration/) и вспомогательные материалы (install/);

● версия релиза фиксируется в журнале учёта организации;

● одновременно с дистрибутивом передаётся полный комплект документации.

2.2. Процессы организационного обеспечения жизненного цикла RSS

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

2.2.1. Процесс управления моделью жизненного цикла

Цель – определение, поддержка и обеспечение применения единой модели жизненного цикла для RSS.

В результате успешного осуществления процесса управления моделью жизненного цикла:

● определена и зафиксирована настоящая модель жизненного цикла RSS на основе ГОСТ Р ИСО/МЭК 12207-2010;

● модель включает процессы соглашения, организационного обеспечения, управления, технические процессы и поддержку RSS;

● ответственным за актуализацию модели назначен руководитель Организации;

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

2.2.2. Процесс управления инфраструктурой

Цель – обеспечение и поддержание необходимой инфраструктуры для выполнения всех процессов жизненного цикла RSS.

В результате успешного осуществления процесса управления инфраструктурой:

● определён и поддерживается состав инфраструктуры Организации;

● обеспечено наличие следующих компонентов инфраструктуры:

o система контроля версий (GitLab CE);

o тестовые стенды для верификации обновлений;

o среда для регрессионного и нагрузочного тестирования;

o хранилище офлайн-архивов дистрибутивов и образов Docker;

● инфраструктура сопровождается, контролируется и модифицируется по мере необходимости;

● определено влияние конфигурационных изменений на инфраструктуру.

2.2.3. Процесс управления людскими ресурсами

Цель – обеспечение процессов жизненного цикла RSS необходимыми человеческими ресурсами и поддержание их компетенций.

В результате успешного осуществления процесса управления людскими ресурсами:

● определены роли и квалификационные требования к персоналу (см. раздел 3 настоящего документа);

● осуществляется подбор персонала (системные аналитики, специалисты поддержки, руководитель проекта);

● проводится внутреннее обучение сотрудников по продукту RSS, включая архитектуру, процедуры установки и обновления, типовые сценарии эксплуатации;

● персонал обеспечивается необходимыми средствами труда;

● компетенции сотрудников поддерживаются через курсы повышения квалификации и изучение новых технологий.

2.2.4. Процесс управления качеством

Цель – обеспечение соответствия процессов жизненного цикла RSS установленным требованиям к качеству.

В результате успешного осуществления процесса управления качеством:

● установлены цели в области качества для каждого релиза RSS;

● планы обеспечения качества включают: компонентное тестирование, интеграционное тестирование, рецензирование архитектуры, нагрузочное тестирование, приёмочные испытания;

● проводятся периодические ревизии планов обеспечения качества;

● осуществляется мониторинг состояния совершенствования продукта;

● при выявлении отклонений целей качества предпринимаются корректирующие действия;

● результаты корректирующих действий фиксируются и доводятся до заинтересованных сторон в пределах Организации;

● ведётся учёт обращений заказчиков для анализа и предотвращения повторения проблем.

2.3. Процессы управления

Данная группа процессов устанавливает порядок управления процессами, связанными с поставкой и сопровождением RSS в Организации.

2.3.1. Процесс планирования

Цель – формирование и поддержание планов, определяющих порядок выполнения процессов жизненного цикла RSS.

В результате успешного осуществления процесса планирования:

● для каждого релиза RSS формируется план работ, включающий состав задач, сроки, ответственных специалистов и необходимые ресурсы;

● план согласовывается с руководителем проекта;

● план пересматривается и корректируется при изменении требований, сроков или состава работ.

2.3.2. Процесс оценки

Цель – оценка состояния и хода выполнения процессов жизненного цикла RSS.

В результате успешного осуществления процесса оценки:

● регулярно оценивается статус выполнения задач по каждому релизу RSS;

● проводится анализ отклонений от плана и причин их возникновения;

● результаты оценки фиксируются и доводятся до заинтересованных сторон внутри Организации.

2.3.3. Процесс управления решениями

Цель – принятие решений, необходимых для достижения целей процессов жизненного цикла RSS.

В результате успешного осуществления процесса управления решениями:

● решения, касающиеся выбора технологий, архитектурных изменений, состава релиза и приоритетов доработок, принимаются на основе анализа доступной информации;

● ответственным за принятие решений назначен руководитель Организации;

● решения фиксируются в GitLab, в документации или в протоколах совещаний.

2.3.4. Процесс управления рисками

Цель – выявление, анализ и управление рисками, возникающими в ходе выполнения процессов жизненного цикла RSS.

В результате успешного осуществления процесса управления рисками:

● определяются возможные риски, влияющие на поставку и сопровождение RSS (срыв сроков, несовместимость сред, уязвимости, потеря данных);

● проводится оценка вероятности наступления рисков и степени их влияния;

● разрабатываются меры по снижению или устранению рисков;

● риски регулярно пересматриваются и актуализируются.

2.3.5. Процесс управления конфигурациями

Цель – обеспечение целостности и управляемости конфигурации RSS на всём протяжении жизненного цикла.

В результате успешного осуществления процесса управления конфигурациями:

● ведётся версионирование всех компонентов RSS (ядро, система интеграции, образы Docker, документация);

● фиксация версий выполняется с использованием GitLab CE (репозиторий исходного кода) и журнала учёта организации (архив дистрибутивов);

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

● любое изменение, влияющее на конфигурацию продукта, согласовывается руководителем проекта.

2.3.6. Процесс управления информацией

Цель – обеспечение своевременного предоставления и сохранности информации, необходимой для выполнения процессов жизненного цикла RSS.

В результате успешного осуществления процесса управления информацией:

● техническая и проектная информация (архитектура, API, инструкции, заметки к релизам) хранится в GitLab и репозитории документации;

● информация доступна уполномоченным сотрудникам Организации;

● обеспечивается резервное копирование документации и репозитория;

● информация предоставляется заказчику в объёме, определённом договором.

2.3.7. Процесс измерений

Цель – сбор, анализ и использование данных для оценки эффективности процессов жизненного цикла RSS.

В результате успешного осуществления процесса измерений:

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

● результаты измерений используются для анализа и совершенствования процессов;

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

2.4. Технические процессы

Данная группа процессов устанавливает порядок технической деятельности по эксплуатации, сопровождению и выводу из эксплуатации RSS.

2.4.1. Процесс эксплуатации

Цель – обеспечение функционирования экземпляра RSS на стороне заказчика.

В результате успешного осуществления процесса эксплуатации:

● развёртывание выполняется администратором заказчика или подрядчиком в соответствии с «Инструкцией по установке и запуску RSS»;

● осуществляется ввод в эксплуатацию, включающий приёмочные проверки и обучение администраторов и аналитиков;

● обеспечивается ежедневное функционирование: мониторинг состояния контейнеров, очередей, дисков; резервное копирование (выполняется заказчиком);

● оказывается консультационная поддержка заказчика по настройке и решению проблем (см. раздел 3).

2.4.2. Процесс сопровождения

Цель – устранение неисправностей и совершенствование RSS.

В результате успешного осуществления процесса сопровождения:

● организован приём заявок от заказчика (L1 – вопросы пользователей, L2 – сбои сервиса, L3 – дефекты кода);

● проводится диагностика: анализ логов (Docker, Laravel, ClickHouse), состояния очередей, сетевого сканера;

● выполняется исправление: выпуск патча (корректирующего обновления) или изменение конфигурации;

● осуществляется верификация исправления на тестовом стенде;

● производится поставка обновления в виде нового офлайн-архива или инструкции по замене образов;

● выполняются доработки по запросам заказчиков (в рамках договора);

● поддерживаются предыдущие версии в соответствии с условиями договора;

● релизные заметки включают описание изменений, инструкции по миграции БД, новые переменные окружения.

2.4.3. Процесс вывода из эксплуатации

Цель – прекращение функционирования RSS на стороне заказчика с сохранением или уничтожением данных.

В результате успешного осуществления процесса вывода из эксплуатации (производится у заказчика):

● согласовываются сроки и порядок остановки;

● производится остановка всех сервисов (docker compose down);

● выполняется архивация или уничтожение данных в томах (PostgreSQL, ClickHouse, Redis, RabbitMQ) в соответствии с политикой заказчика;

● осуществляется отзыв API-ключей и отключение интеграций;

● документируется факт снятия с учёта.

2.5. Процессы поддержки программных средств

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

2.5.1. Процесс документирования

Цель – создание, актуализация и поддержание документации RSS.

В результате успешного осуществления процесса документирования:

● создаётся и актуализируется документация: общее описание, руководство пользователя, инструкция по установке, описание жизненного цикла, описание технической архитектуры;

● документация ведётся в форматах .md и .docx, хранится в репозитории документации;

● одновременно с дистрибутивом заказчику передаётся полный комплект документации, включающий настоящее описание, руководство по эксплуатации и руководство по установке и настройке.

2.5.2. Процесс верификации

Цель – подтверждение того, что результаты каждого процесса жизненного цикла RSS соответствуют установленным требованиям.

В результате успешного осуществления процесса верификации:

● проводится проверка соответствия каждого компонента RSS (ядро, модуль интеграции, API, панель управления) требованиям, указанным в техническом задании;

● выполняются автоматизированные тесты (компонентные, интеграционные) для подтверждения корректности работы RSS;

● результаты верификации фиксируются и доводятся до руководителя проекта.

2.5.3. Процесс валидации

Цель – подтверждение того, что RSS соответствует потребностям и ожиданиям заказчика.

В результате успешного осуществления процесса валидации:

● проводится приёмочное тестирование RSS с участием заказчика (или его представителя);

● проверяется выполнение требований в реальных условиях эксплуатации;

● результаты валидации оформляются актом приёма-передачи;

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

2.5.4. Процесс совместного анализа

Цель – оценка состояния и результатов процессов жизненного цикла RSS совместно с заинтересованными сторонами.

В результате успешного осуществления процесса совместного анализа:

● проводятся периодические совещания с заказчиком (при необходимости) для обсуждения статуса доработок и планов;

● результаты анализа фиксируются в протоколах совещаний или в GitLab;

● по результатам анализа принимаются решения о корректировке планов и состава работ.

2.5.5. Процесс аудита

Цель – независимая оценка соответствия процессов жизненного цикла RSS установленным требованиям и планам.

В результате успешного осуществления процесса аудита:

● проводятся внутренние аудиты процессов сопровождения и поставки RSS;

● аудит выполняется уполномоченным сотрудником Организации, не участвующим непосредственно в проверяемом процессе;

● результаты аудита фиксируются в отчёте;

● при выявлении несоответствий разрабатываются корректирующие мероприятия.

2.5.6. Процесс разрешения проблем

Цель – обнаружение, анализ и устранение проблем, возникающих в ходе жизненного цикла RSS.

В результате успешного осуществления процесса разрешения проблем:

● организован приём заявок от заказчика (L1 – вопросы пользователей, L2 – сбои сервиса, L3 – дефекты кода);

● проводится диагностика проблемы (анализ логов Docker, Laravel, ClickHouse, состояния очередей, сетевого сканера);

● выполняется исправление: выпуск патча или изменение конфигурации;

● верификация исправления на тестовом стенде;

● поставка обновления в виде нового офлайн-архива или инструкции по замене образов;

● ведётся учёт обращений заказчиков для анализа и предотвращения повторения проблем.

3. Сведения о персонале организации, осуществляющем сопровождение и техническую поддержку

Устранение сбойных ситуаций, техническую поддержку и совершенствование ПО обеспечивает ООО «БИТ ПЛЮС» . Персонал включает следующие категории специалистов:

РОЛЬ	КЛЮЧЕВАЯ КВАЛИФИКАЦИЯ
Системный аналитик	Участвует в сборе требований, документировании.
Специалист поддержки (L2/L3)	Знание архитектуры RSS, умение читать логи (Docker, Laravel, syslog), опыт настройки интеграций (DLP, SIEM, API). Работает с тикет-системой.
Руководитель проекта	Управляет командой, планирует релизы, эскалирует критические инциденты.

Все специалисты проходят внутреннее обучение по продукту, включающее:

● Архитектуру и технологический стек RSS.

● Процедуры установки, обновления и резервного копирования.

● Типовые сценарии эксплуатации и ошибки.

4. Фактические адреса размещения инфраструктуры и персонала

ОБЪЕКТ	АДРЕС
Инфраструктура Организации	193149, Ленинградская область, Всеволожский район, п/р Центральное Отделение, д. 18, литер А, офис 16
Место хранения исходного кода (GitLab CE)	193149, Ленинградская область, Всеволожский район, п/р Центральное Отделение, д. 18, литер А, офис 16 (сервер Организации)
Хранение объектного кода и образов Docker	193149, Ленинградская область, Всеволожский район, п/р Центральное Отделение, д. 18, литер А, офис 16 (архив на внутренних серверах)
Рабочие места сотрудников	193149, Ленинградская область, Всеволожский район, п/р Центральное Отделение, д. 18, литер А, офис 16
Служба поддержки (техподдержка)	193149, Ленинградская область, Всеволожский район, п/р Центральное Отделение, д. 18, литер А, офис 16