Жизненный цикл ПО
Жизненный цикл программного продукта обеспечивается в соответствии с требованиями ГОСТ Р ИСО/МЭК 12207-2010. Основные процессы жизненного цикла в соответствии с указанным ГОСТ описаны в данном разделе.

1.1. Процесс планирования проекта

Включает в себя этапы:

  • осознания потребности и формирование идеи продукта, участники: Руководитель отдела, аналитик. Документ на выходе: Описание идеи.

  • Взаимодействие с целевой аудиторией (ЦА). Участники: Руководитель отдела, маркетолог, менеджер по продажам, аналитик. Документ на выходе: Техническое задание на разработку.

Подэтапы:

  1. Определение потенциального потребителя;

  2. Выход на потенциального потребителя, проверка гипотезы;

  3. Выявление потребностей заказчика;

  4. Подготовка коммерческого предложения (КП);

  5. Подготовка технического задания (ТЗ).

  • Непосредственное планирование, участники: менеджер проекта, аналитик.

Документ на выходе: План работ.

Подэтапы:

  1. Формирование плана работ;

  2. Оценка трудозатрат.


1.2. Процессы реализации программных средств

1.2.1. Основной процесс реализации В результате успешного осуществления основного процесса реализации программных средств:

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

  • определяются ограничения по технологии реализации проекта; изготавливается программная часть.

Участники: менеджер проекта, аналитик, архитектор системы, разработчик.


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

  • определяются требования к программным элементам системы и их интерфейсам на основе собранных на этапе планирования данных;

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

  • устанавливается совместимость и прослеживаемость между требованиями к программным средствам и требованиями к системе;

  • определяются приоритеты реализации требований к программным средствам;

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

  • требования к программным средствам воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон.

Участники: менеджер проекта, аналитик, архитектор системы

1.2.3. Процессы проектирования программных средств В результате успешной реализации процесса проектирования архитектуры программных средств:

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

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

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

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

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

Участники: менеджер проекта, аналитик, архитектор системы.

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

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

  • изготавливаются программные блоки, определенные проектом;

  • устанавливается совместимость и прослеживаемость между программными блоками, требованиями и проектом;

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

Результатом является разработка MVP (Минимально жизнеспособный продукт от англ. minimum viable product).

Участники: менеджер проекта, программист, тестировщик, аналитик.


Подэтапы применительно к продукту:

  1. Постановка задач на разработку ПО;

  2. Написание кода;

  3. Код review.


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

  • разрабатывается стратегия комплексирования для программных блоков, согласованная с программным проектом и расположенными по приоритетам требованиями к программным средствам;

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

  • программные составные части верифицируются с использованием определенных критериев;

  • программные составные части, определенные стратегией комплексирования, изготавливаются;

  • регистрируются результаты комплексного тестирования;

  • устанавливаются согласованность и прослеживаемость между программным проектом и программными составными частями;

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

Участники: программист, архитектор системы


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

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

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

  • разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного средства при проведении изменений в программных составных частях.

Относительно продукта подразумеваются следующие подэтапы:

  • Модульное тестирование;

  • Сборка версии ПО;

  • Упаковка и размещение версии в репозитории;

  • Размещение версии на тестовом сервере;

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

  • Релиз MVP.

Участники: менеджер проекта, программист, тестировщик.


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

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

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

  • определяются стандарты, которые применяются при разработке программной документации;

  • определяется документация, которая производится процессом или проектом;

  • указываются, рассматриваются и утверждаются содержание и цели всей документации;

  • документация разрабатывается и делается доступной в соответствии с определенными стандартами;

  • документация сопровождается в соответствии с определенными критериями.

Участники: менеджер проекта, аналитик, архитектор системы.

1.3.2. Процесс управления конфигурацией программных средств В результате успешного осуществления процесса управления конфигурацией программных средств:

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

  • контролируются модификации и выпуски этих составных частей;

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

  • регистрируется и сообщается статус составных частей и модификаций;

  • гарантируются завершенность и согласованность составных частей;

  • контролируются хранение, обработка составных частей.

Участники: программист, аналитик, архитектор системы.

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

  • разрабатывается стратегия обеспечения гарантии качества;

  • создается и поддерживается свидетельство гарантии качества;

  • идентифицируются и регистрируются проблемы и (или) несоответствия с требованиями;

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

Участники: менеджер проекта, аналитик, архитектор системы.

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

  • разрабатывается и осуществляется стратегия верификации;

  • определяются критерии верификации всех необходимых программных рабочих продуктов;

  • выполняются требуемые действия по верификации;

  • определяются и регистрируются дефекты;

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

Участники: менеджер проекта, аналитик, архитектор системы.

1.3.5. Процесс валидации программных средств В результате успешного осуществления процесса валидации программных средств:

  • разрабатывается и реализуется стратегия валидации;

  • определяются критерии валидации для всей требуемой рабочей продукции;

  • выполняются требуемые действия по валидации;

  • идентифицируются и регистрируются проблемы;

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

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

Участники: менеджер проекта, аналитик, архитектор системы.

1.3.6. Процесс ревизии программных средств В результате успешного осуществления процесса ревизии программных средств:

  • выполняются технические ревизии и ревизии менеджмента на основе потребностей проекта;

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

  • объявляются результаты ревизии всем участвующим сторонам;

  • отслеживаются для закрытия позиции, по которым необходимо предпринимать активные действия, выявленные в результате ревизии;

  • идентифицируются и регистрируются риски и проблемы.

Участники: программист, аналитик, архитектор системы.

1.3.7. Процесс решения проблем в программных средствах В результате успешной реализации процесса решения проблем в программных средствах:

  • разрабатывается стратегия менеджмента проблем;

  • проблемы регистрируются, идентифицируются и классифицируются;

  • проблемы анализируются и оцениваются для определения приемлемого решения (решений);

  • выполняется решение проблем;

  • проблемы отслеживаются вплоть до их закрытия; известно текущее состояние всех зафиксированных проблем.

Более подробно процесс технической поддержки относительно программного продукта «Первый Электронный Рецепт» описан далее.
Описание сопутствующих процессов, обеспечивающих поддержание жизненного цикла ПО после этапа внедрения
Мониторинг

Мониторинг системы осуществляется следующими средствами:

1. ПО Zabbix. Используется для мониторинга состояния ВМ и компонентов системы и рассылки уведомлений администратору при возникновении отказов, ошибок, или при достижении пороговых значений нагрузки на ресурсы ВМ.

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


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

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

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

Техническая поддержка пользователей осуществляется в чате поддержки в модулях приложения ПО и по электронной почте support@1er.app.Процесс поддержки пользователей и решения проблем состоит из следующих этапов:

1. Пользователь создает обращение в техническую поддержку через чат или по электронной почте

2. Специалист первой линии поддержки обрабатывает обращение, консультирует пользователя, если решить кейс не удается, передает задачу на вторую линию поддержки. В случае успешной консультации закрывает обращение на своем уровне.

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

4. Тестировщик должен подтвердить наличие ошибки, при необходимости подключить аналитика для оптимизации БП.

5. Аналитик пишет постановку на доработку ПО для фиксации кейса.

6. Задача попадает на разработчика ПО и по итогу появляется новая bugfix версия ПО.

7. Разработчик применяет изменения на тестовом контуре.

8. Тестировщик проходит необходимые тест-карточки для проверки устранения зафиксированной задачи.

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

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

11. Пользователь проверяет решение обращение, ставит оценку решению кейса.

Участники: специалист технической поддержки первая линия, специалист технической поддержки вторая линия, тестировщик, аналитик, разработчик.


Совершенствование программного обеспечения

Работа по совершенствованию ПО включает в себя два основных направления:

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

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

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

Участники этапа: программист, тестировщик, аналитик, специалисты технической поддержки пользователей.

Этап непрерывных улучшений ПО состоит из еженедельных итераций (спринтов), в рамках которых последовательно проходят этапы: взаимодействие с ЦА, планирование, разработка MVP, релиз MVP, анализ и сбор статистики.

Компетенции сотрудников, участвующих в поддержании ПО