1.1. Жизненный цикл системы

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

1.1.1. Проектирование, разработка ПО

Система представляет из себя Framework, разработанный нами для создание на его основе проектных решений по запросу клиента (не “коробочный продукт”). После получения требований от заказчика, мы выделяем основные сущности, которые заполяются и обрабатываются оператором и имеют движение по процессу (клиент, договор, заявка, услуга и тому подобное) и определяются связи разного рода между этими сущностями различного типа (1 к многому, 1 к 1 или многое ко многому). На каждую сущность создается bps-приложение в системе, через наследование от абстрактной реализации приложения bps (которое поставляется в составе ядра). Далее мы следуем концепции итерационной разработки, сразу создавая у этих сущностей известный нам на начальных этапах набор параметров, настраивая их для редактирования всем и выкладываем на тест, выдавая доступ к тесту для заказчика и предлагаем формулировать требования на следующий этап. Далее наким же образом настраивается процесс, добавляются дополнительные параметры в карточки сущностей, настраивается точный доступ к параметрам на разных этапах. Добавляется интеграция и дополнительный кастомный функционал. При этом, заказчик может пробовать начать работу на любом удобном для него этапе внедрения, так как с первых дней разработки, заказчику уже доступен базовый функционал, который по мере разработки просто обрастает деталями.

1.1.2. Тестирование

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

1.1.3. Приобретение системы и поставка

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

1.1.4. Эксплуатация системы

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

1.1.5. Документирование конфигурации

Мы оказываем услуги разработки. Бизнес-аналитики находятся на стороне заказчика. Они ставят задачи по добавлению функционала в систему и ведут документацию логики конфигурации и актуализируют ее по мере выставления нам новых задач, изменяющих и добавляющих функционал.

1.1.6. Обучение и квалификация персонала

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

1.1.7. Поддержка версий

В настоящее время, существуют 4 мажорных версии ядра, которые использутся для активных проектов. Последняя версия (4-я) находится в стадии альфа-тестирования основана на стеке ReactJS + Flask + SQLAlchemy. Текущая стабильная (3-я) используется на бОльшей части проектов и основана на стеке Flask + SQLAlchemy. Старая стабильная (2-я) поддерживается нами и работает на меньшей части проектов и имеет стек django + PostgreSQL. Первая версия на текущий момент старая и не используется. Конфигации всех мажорных версий не совместимы между собой и требуют портирования. Номерация минорных версий не ведется, разработка функционала производится со 100% обратной совместимостью имеющими с конфигурациями.

1.1.8. Устранение сбойных ситуаций

Возможно возникновение ситуаций, приводящее к порче (полной или частичной) данных экземпляра системы. Работающий экземпляр системы можно разделить на несколько блоков, которые характеризуются различными мероприятиями по их эксплуатации.

1) База данных Необходимо обеспечить инкрементное резервное копирование базы данных на отдельный сервер резервного копирования данных, который (желательно) находится в отдельном дата-центре. В случае критического сбоя системы по различным причинам (в том числе и не зависимым от экземпляра Сфера BPS) будет возможность восстановить данные в состояние, непосредственно предшевствующему сбою с потерей данных на уровне нескольких минут.

2) Исходный код конфигурации и ядра системы Отдельных мероприятий этот пункт не требует, код конфигурации и ядра находятся под системой контроля версий git (также можно использовать и другие системы). В случае сбоя необходимо клонировать репозиторий и загрузить из него последний релиз master-ветки.

3) Медиа-данные - файлы, которые появляются в результате работы системы (загружаются пользователями, генерируемые или получаемые файлы писем электронной почты eml, файлы лога о активностях системы, которые требуется хранить). Рекомендуется воспользоваться утилитой rsync для инкрементного копирования файлов на удаленый сервер. В случае сбоя, используя эту же утилиту, необходимо переместить файлы обратно на сервер с восстановленным экземпляром

Более подробно это описано в разделе обслуживания системы