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

ООО «Икс Драй» разрабатывает и сопровождает платформу цифрового клиентского сервиса и выездной логистики для сферы профессионального ухода за вещами. Платформа состоит из трёх продуктов на общей серверной части:

- клиентское мобильное приложение BIANCA для iOS и Android — оформление заявки на сбор вещей курьером, отслеживание исполнения заказа, согласование доставки, онлайн-оплата и уведомления на каждом этапе; приложение включено в Единый реестр российского ПО;
- веб-панель управления — витрина услуг, контент приложения и push-уведомления;
- CRM-система логистики — рабочее место контакт-центра для ведения заявок на сбор и доставку и распределения их по временным слотам и передачи во внешние сервисы маршрутизации курьеров.

Платформа находится в промышленной эксплуатации в сети химчисток BIANCA. Она охватывает внешний, клиентский контур: сведения о составе, стоимости и готовности заказа платформа получает из внешней учётной системы по API. Учётной или производственной системой платформа не является.

Основными процессами жизненного цикла программной продукции являются:

- проектирование;
- разработка ПО;
- тестирование и отладка;
- сопровождение ПО.

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

Планирование и разработка требований к процессам жизненного цикла продукции регламентированы стандартами с учётом особенностей разрабатываемого продукта:

- ГОСТ Р ИСО/МЭК 12207-2010 «Процессы жизненного цикла программных средств»;
- ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
- ГОСТ 19.102-77 «Стадии разработки».

Жизненный цикл создания продукции включает следующие стадии:

- проектирование;
- разработка;
- тестирование и отладка;
- сопровождение.

3. Проектирование программного обеспечения

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

Также проводится анализ существующего программного обеспечения.

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

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

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

Состав может быть изменён в зависимости от особенностей программного обеспечения.

4. Разработка программного обеспечения

Процесс разработки включает:

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

Макетирование не является обязательным этапом. При разработке программного обеспечения без интерфейса создание пользовательского интерфейса не предусмотрено.

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

При разработке используется доступное стороннее программное обеспечение с открытым исходным кодом.

На этом этапе разрабатывается рабочая документация на программное обеспечение. Пакет документов согласовывается с заказчиком в индивидуальном порядке.

Как правило, пакет рабочей документации включает следующие документы:

- руководство пользователя (администратора);
- инструкция по эксплуатации;
- общее описание системы;
- программа и методика испытаний.

5. Тестирование и отладка

Тестирование обязательно проводится после завершения разработки программного обеспечения.

Тестирование проводят сотрудники организации на основе разработанной документации.

Для тестирования и отладки собирается стенд и выдаётся задание на тестирование.

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

Тестирование проводится для следующих целей:

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

Каждый дефект фиксируется с указанием статуса и даты устранения.

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

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

Среды разработки и тестирования являются внутренними средами организации.

6. Управление обновлениями программного обеспечения

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

Платформа регулярно развивается:

- исправляются неисправности;
- появляются новые функции;
- оптимизируется скорость работы;
- обновляется интерфейс.

Обновление программного обеспечения предусматривает:

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

Сотрудник, ответственный за процесс обновления:

- разрабатывает политику выпуска и планирования релизов;
- планирует развёртывание релизов и обновлений;
- передаёт релиз на тестирование;
- оповещает участников процесса обновления;
- организует распространение и установку релизов и обновлений.

Основные причины выпуска версии продукта:

- разработка новой функциональности;
- исправление ошибок.

Версия продукта выпускается на основе релиза, успешно прошедшего тестирование. Номер версии продукта присваивается по номеру релиза.

7. Сопровождение

7.1. Техническая поддержка

Организация осуществляет техническую поддержку платформы в период эксплуатации:

- предоставляет документацию по установке и настройке;
- устраняет недостатки в работе программного обеспечения, выявленные в ходе эксплуатации.

Техническая поддержка программного обеспечения — это процесс обнаружения, фиксации и принятия решения о работе с дефектом, неисправностью или новой функциональностью.

Техническая поддержка состоит из трёх уровней:

- первый уровень — приём и регистрация обращений (инцидентов) пользователей, информационная поддержка (консультации по работе с платформой), передача сведений о некорректной работе на второй уровень;
- второй уровень — обслуживание программного обеспечения, в том числе сопровождение программных средств, обеспечивающих его функционирование, и устранение ошибок по запросам, поступившим с первого уровня;
- третий уровень — управление обновлениями.

7.2. Устранение неисправностей

Неисправность, обнаруженная в ходе эксплуатации, фиксируется службой поддержки с указанием приоритета.

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

Инцидент — любое событие, которое не является элементом нормального функционирования платформы и оказывает или способно оказать влияние на предоставление услуг, прерывая их или снижая их качество.

Типы инцидентов:

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

Инциденты классифицируются по приоритету:

- первый приоритет (критический) — инцидент приводит к остановке или полной потере работоспособности программного обеспечения: основной набор функций недоступен, под угрозой целостность и конфиденциальность данных, программное обеспечение работает в аварийном режиме;
- второй приоритет (высокий) — инцидент приводит к значительной потере работоспособности: критические функции недоступны независимо от числа пользователей, применимого обходного пути нет, но программное обеспечение сохраняет работоспособность в ограниченном объёме;
- третий приоритет (средний) — инцидент приводит к несущественной потере работоспособности: возникают неудобства в работе или необходимость использовать обходные пути;
- четвёртый приоритет (низкий) — инцидент не приводит к потере работоспособности: незначительная ошибка, неудобство, ошибка в документации и т. п., не препятствующие работе.

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

Процесс управления инцидентами состоит из следующих этапов:

- Приём и регистрация инцидента.
- Классификация инцидента по приоритету и уведомление пользователя о регистрации: номер инцидента и срок решения направляются на электронную почту пользователя.
- Назначение исполнителя (или группы исполнителей).
- Мониторинг хода работ по инциденту.
- Решение и закрытие инцидента.

Сведения о закрытии инцидента фиксируются; при необходимости пользователю направляется сообщение о решении на электронную почту.

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

Связаться с сотрудниками технической поддержки можно через чат в мобильном приложении.

Численность и квалификация персонала технической поддержки определяются задачами и объёмом работ на каждом уровне.

В отделе технической поддержки предусмотрены следующие должности:

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