ПО «Центр охраны»

Профессиональное ПО для организации пультовой охраны в России и странах ближнего зарубежья

Информация, необходимая для установки ПО

Дистрибутив для новой установки «Центра Охраны»
‍(версия 5.11.1309 от 21.12.2022)

Предназначен для выполнения новой установки «Центра Охраны» версии 5.11.1309.(с предыдущих версий до версии 5.11.1309)Перед обновлением Центра Охраны сделайте резервную копию базы данных.

Для полной установки «Центра Охраны» нужно предварительно установить SQL Server:Инструкция

‍1. История версий «Центра Охраны»
‍
‍2. Руководство по установке Центра Охраны
‍В документе приведены требования к системе, предназначенной для установки «Центра Охраны»,описание процедуры установки, а также инструкция по установке SQL Server.

Информация, необходимая для эксплуатации ПО

‍Руководство по эксплуатации Центра Охраны
‍Развернутое руководство по эксплуатации «Центра Охраны» от 28.08.2020.

Описание функциональных характеристик

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

Центр Охраны предлагает оператору идеологию отработки тревог: чёткое следование сценарию отработки и полная фиксация действий дежурного оператора, охранников и клиентов.

Ведение журнала событий
Журнал показывает принятые события и состояния групп реагирования. Классы событий отличаются друг от друга по цвету, работает сортировка по столбцам журнала. Во вкладке «все» отображаются только значимые события, а тестовые и повторные — отфильтровываются. Механизм фильтрации событий достаточно гибок и позволяет чётко определить, какие события являются для оператора важными, а что можно опустить.

Быстрый просмотр объектов
Во всплывающем окне оператор видит название и адрес объекта, тревожные разделы, последнее событие, взятия/снятия и статус вызова группы реагирования.

Устранение неисправностей в ходе эксплуатации ПО

Для устранения неисправностей ПО “Центр Охраны” в компании внедрён регламент обработки отчётов об обнаруженных неисправностях.Входом процесса является заявка, созданная пользователем в корпоративной системе службы поддержки клиентов “Okdesk”. Дальнейшие шаги по обработке заявки:

1. Подтверждение факта наличия неисправности специалистом по обеспечению качества.
‍
2. При условии подтверждения факта наличия неисправности должна быть создана задача в системе управления разработкой “Jira” с типом “Неисправность”. Атрибуты задачи:
— Версия ПО;
— Шаги воспроизведения неисправности;
— Фактический результат;
— Ожидаемый результат.

3. Менеджер команды разработки мониторингового ПО совместно с командой разработки формирует оценку трудозатрат и сроков по устранению неисправности. Работы включаются в план разработки.

4. После внедрения изменений, направленных на устранение неисправности, формируется версия ПО со статусом “релиз-кандидат”.

5. Инженеры по тестированию планируют и реализуют комплекс мер по тестированию версии.

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

Жизненный цикл задачи в “Jira” с типом “Неисправность”:

• NEW - начальный этап, задача создана на основе заявки клиента в корпоративной системе “OKdesk”;
• CLARIFICATION - неисправность находится на этапе уточнения её наличия в ПО;
• VERIFIED - наличие неисправности и шагов по её воспроизведению подтверждено инженерами по тестированию;
• READY FOR DEV – задача может быть взята в работу командой разработки мониторингового ПО; задача берётся в работу согласно плану разработки, который актуализируется менеджером команды разработки мониторингового ПО каждые две недели;
• IN PROGRESS – задача в работе в команде разработки мониторингового ПО;
• REVIEW – программный код, разработанный в рамках выполнения задачи, проходит ревью в команде разработки мониторингового ПО;
• READY FOR STAGING – реализованные исправления готовы к включению в сборку версии ПО “Центр Охраны” со статусом “релиз-кандидат”;
• READY FOR QA – разработанная или переработанная функциональность включена в сборку версии ПО “Центр Охраны” со статусом “релиз-кандидат”, сборка готова к передачу в тестирование силами инженеров по тестированию;
  — результатом тестирования является отчёт о тестировании;
  — если тестирование было признано успешным, то задача переводится на этап READY FOR PROD;
  – в противном случае, задача переводится обратно на этап READY FOR DEV;
• READY FOR PROD – разработанная или переработанная функциональность готова прошла тестирование и готова к передаче клиентам;
  — если функциональность должна быть включена в релизную версию ПО “Центр Охраны”, то проводится её развёртывание и задача переводится на этап PROD;
  — в противном случае задача сразу переводится на этап DONE;
• PROD – разработанная или переработанная функциональность включена в версию ПО “Центр Охраны” со статусом “релиз”.
• После публичного выпуска версии со статусом “релиз” задача переводится с статус “DONE”.
• ABORTED - задачи, по которым принято решение не производить каких-либо изменений ввиду отсутствия воспроизводимости или по причине неправильной настройки и эксплуатации ПО “Центр Охраны” клиентом, которое привело к сбою.

Выходом процесса являются:
— Версия ПО “Центр Охраны” со статусом “релиз”, доступная клиентам;
— Актуальные примечания к релизу.

Совершенствование ПО

Совершенствование ПО “Центр Охраны” происходит в рамках установленного в компании регламента обработки предложений по улучшению продукта.

Входом процесса являются:
1. Заявка с предложение по улучшению, созданная пользователем в корпоративной системе службы поддержки клиентов “OKdesk”. Для дальнейшей обработки на основе этой заявки менеджером команды разработки мониторингового ПО создаётся задача в системе управления разработкой “Jira” с типом “Улучшение”.
2. Задача с типом “Улучшение”, созданная инженерами по тестированию в процессе прохождения этапа тестирования ПО.

Дальнейшие шаги по обработке задачи с типом “Улучшение”:

1. Менеджер команды разработки мониторингового ПО совместно с командой разработки формирует оценку трудозатрат и сроков по устранению неисправности.

2. Менеджер по развитию ПО “Центр Охраны” проводит исследование, на основании которого выполняет оценку пользовательской ценности предполагаемой доработки.

3. Менеджер по развитию ПО “Центр Охраны” принимает решение о целесообразности внедрения запроса на улучшение на основе вышеперечисленных оценок.

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

5. После внедрения изменений, направленных на устранение неисправности, формируется версия ПО со статусом “релиз-кандидат”.

6. Инженеры по тестированию планируют и реализуют комплекс мер по тестированию версии.

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

Жизненный цикл задачи в “Jira” с типом “Улучшение”:

• OPEN – начальный этап:
  — в отношении задач, находящихся на этом этапе, менеджер команды разработки мониторингового ПО совместно с командой разработки формирует оценку трудозатрат и сроков по устранению неисправности, а  менеджер по развитию ПО “Центр Охраны” проводит исследование, на основании которого выполняет оценку пользовательской ценности предполагаемой доработки. На основе анализа полученных оценок менеджер по развитию ПО “Центр Охраны” принимает решение о целесообразности доработки;
  — задачи, работы по которым не планируются, должны быть переведены в статус ABORTED;
  — задачи, которые будут взяты в работу, менеджер команды разработки мониторингового ПО должен перевести на этап READY FOR DEV и убедиться в том, что соответствующие задачи обладают полным, корректным и непротиворечивым описанием задачи, достаточным для выполнения её  силами команды разработки мониторингового ПО и тестирования силами инженеров по тестированию;
• READY FOR DEV – задача может быть взята в работу командой разработки мониторингового ПО; задача берётся в работу согласно плану разработки, который актуализируется менеджером команды разработки мониторингового ПО каждые две недели;
• IN PROGRESS – задача в работе в команде разработки мониторингового ПО;
• REVIEW – программный код, разработанный в рамках выполнения задачи, проходит ревью в команде разработки мониторингового ПО;
• READY FOR STAGING – разработанная или переработанная функциональность готова к включению в сборку версии ПО “Центр Охраны” со статусом “релиз-кандидат”;
• READY FOR QA – разработанная или переработанная функциональность включена в сборку версии ПО “Центр Охраны” со статусом “релиз-кандидат”, сборка готова к передачу в тестирование силами инженеров по тестированию;
  — результатом тестирования является отчёт о тестировании;
  – если тестирование было признано успешным, то задача переводится на этап READY FOR PROD;
  — в противном случае, задача переводится обратно на этап READY FOR DEV;
• READY FOR PROD – разработанная или переработанная функциональность готова прошла тестирование и готова к передаче клиентам;
  — если функциональность должна быть включена в релизную версию ПО “Центр Охраны”, то проводится её развёртывание и задача переводится на этап PROD;
  — в противном случае задача сразу переводится на этап DONE;
• PROD – разработанная или переработанная функциональность включена в версию ПО “Центр Охраны” со статусом “релиз”.
• После публичного выпуска версии со статусом “релиз” задача переводится с статус “DONE”.

Выходом процесса являются:
— Версия ПО “Центр Охраны” со статусом “релиз”, доступная клиентам;
— Актуальные примечания к релизу;
— Актуальные пользовательская документация.

Информация о персонале

Устранение неисправностей и совершенствование ПО “Центр Охраны” обеспечивают:

менеджер команды разработки мониторингового ПО:
— Елена Малиновская;

менеджер по развитию ПО “Центр Охраны”:
— Марк Львов;

команда разработки мониторингового ПО:
— Сергей Устинов;

инженеры по тестированию:
— Андрей Балакин;
— Любовь Якутина.