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

Основными направлениями деятельности ООО “Икс Драй” являются разработка на базе новой перспективной архитектуры полнофункциональной ERP-системы XDry, в полной мере адаптированной под текущие потребности предприятия, и ее запуск в рамках пилотной зоны с целью тестирования и адаптации с последующим постепенным переходом к полноформатной эксплуатации новой системы и замены устаревших IT-решений на основе системы АГБИС, которыми предприятие пользуется в настоящее время. На первом этапе предполагается создание минимально жизнеспособного продукта – MVP (Minimum Viable Product), который будет функционировать и дорабатываться в рамках ограниченной пилотной зоны.

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

Основными процессами жизненного цикла программной продукции являются: - Проектирование;
- Разработка ПО;
- Тестирование и отладка;
- Сопровождение ПО.

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

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

- ГОСТ Р ИСО/МЭК 12207-2010 ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ
- ГОСТ 34.601-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ СТАДИИ СОЗДАНИЯ
- ГОСТ 19.102-77 СТАДИИ РАЗРАБОТКИ

Жизненный цикл процесса создания продукции включает следующие стадии:
- Проектирование;
- Разработка;
- Тестирование и отладка;
- Сопровождение.

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

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

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

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

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

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

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

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

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

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

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

Зачастую пакет рабочей документации ограничивается следующими документами:
- Руководство пользователя (администратора);
- Инструкция по эксплуатации;
- Общее описание системы;
- Программа и методика испытаний;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выпуск версии продукта осуществляется на основе релиза, который прошел удачное тестирование.

Версия продукту присваивается от версии релиза.

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

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

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

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

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

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

При обнаружении неисправности в процессе эксплуатации дефект фиксируется службой поддержки в следующих статусах: высокий, средний, низкий.

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

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

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

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

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

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

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

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

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