Перейти к содержанию

Жизненный цикл поддержки программного обеспечения

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

«Облачная платформа Видеонаблюдение Ростелеком» (далее платформа) – это программное решение, которое предназначено для получения видеопотоков от клиентских устройств, анализа видеопотока программными средствами, хранения и предоставления видеоархивов и событий, трансляции и управления потокового видео с камер, предоставления отчетов с возможностью дступа для пользователей через программные модули:

  • Личный кабинет Видеонаблюдение Ростелеком,
  • Мобильное приложение «Видеонаблюдение Ростелеком» для ОС Android,
  • Мобильное приложение «Видеонаблюдение Ростелеком» для ОС iOS.

Жизненный цикл разработки

Методика разработки

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

Участники процесса разработки

Участники процесса разработки образуют скрам-команду.

Состав скрам-команды:

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

Цикл разработки

В рамках Scrum-подхода разработка ведётся циклами, называемыми «спринтами». Каждый спринт длится две недели и состоит из следующих этапов:

  1. Владелец продукта готовит «бэклог» — приоритизированный список пожеланий и бизнес-требований по доработке продукта.
  2. Во время планирования спринта команда выбирает часть элементов из бэклога и из них формирует список целей на спринт.
  3. Команда ежедневно проводит «стендап» — встречу, на которой члены команды оценивают прогресс по спринту.
  4. В течение спринта скрам-мастер поддерживает фокус команды на целях спринта.
  5. В конце спринта команда демонстрирует заказчику достигнутые результаты, а полностью готовые функции делает доступными пользователям.
  6. Спринт заканчивается «ретроспективой» — встречей команды, на которой члены команды оценивают результаты спринта.
  7. В начале следующего спринта команда выбирает следующую часть бэклога, и цикл повторяется.

Процесс разработки

После того, как команда разработки получила бизнес-требования, процесс разработки делится на три этапа:

  1. проектирование и планирование,
  2. разработка и тестирование,
  3. релиз.
Проектирование и планирование
  1. Аналитик декомпозирует бизнес-требования на «фичи» и «истории».

«Фича» — это новая функция, возможность программы.

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

  1. Владелец продукта приоритизирует истории и выбирает одну или несколько для дальнейшей проработки.
  2. Аналитик и архитектор определяют высокоуровневые сценарии работы фичей.
  3. Скрам-команда проводит встречу-груминг, на которой приоритизирует истории.
  4. Аналитик и архитектор выбирают технологии и подход для разработки выбранных историй.
  5. Команда разработки проводит встречу-груминг, на которой команда, на основании историй, создаёт конкретные задачи по разработке.
  6. Скрам-команда проводит «планирование спринта» — встречу, на которой выбирает, над какими задачами команда разработки будет работать в спринте.
Разработка и тестирование

На этапе разработки и тестирования команда разработки выполняет два типа задач:

  • разработка — добавление в продукт новых возможностей,
  • доработка — совершенствование существующих возможностей.

Все участники команды разработки работают в одном спринте, но над разными задачами:

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

На этом же этапе проводится тестирование продукта. Если тестировщик находит ошибку, он фиксирует её как «баг» либо как «дефект».

«Баг» — это ошибка, которую разработчик должен исправить во время текущего спринта.

«Дефект» — это ошибка, которую нужно исправить в следующих спринтах, потому что она не связана напрямую с выполнением задач, над которыми идёт работа в этом спринте.

Релиз

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

Изменения, которые не готовы к релизу в текущем спринте, переносятся на следующий спринт.

Обновлённой версии ПО при релизе присваивается новый номер в соответствии с принципами семантического версионирования.

Сторонние компоненты

Список сторонних компонентов, используемых при разработке:

  • СУБД:
  • PostgreSQL,
  • ClickHouse,
  • Redis (open-source edition),
  • Elasticsearch,
  • Apache Cassandra.
  • Платформы:
  • RabbitMQ — система обмена сообщениями,
  • NATS — система обмена сообщениями.
  • Библиотеки

  • Android:

    • com.atlassian.commonmark:commonmark:0.10.0
    • com.google.zxing:core:3.3.3
    • com.octo.android.robospice:robospice:1.4.14
    • com.squareup.okhttp:logging-interceptor:2.7.5
    • com.yandex.android:mobmetricalib:3.5.3
    • joda-time:joda-time:2.10.1
    • com.neovisionaries:nv-websocket-client:2.3
    • com.koushikdutta.ion:ion:2.2.1
    • com.google.dagger:dagger:2.24
    • com.google.dagger:dagger-compiler:2.24
    • com.google.dagger:dagger-android:2.24
    • com.google.dagger:dagger-android-processor:2.24
    • com.google.dagger:dagger-android-support:2.24
    • io.gsonfire:gson-fire:1.8.0
    • org.apache.maven:maven-artifact:3.6.1
    • commons-io:commons-io:2.6
    • com.google.code.gson:gson:2.8.5
    • com.github.ChuckerTeam.Chucker:library:3.0.1
    • com.github.ihsanbal:LoggingInterceptor:3.0.0
    • com.squareup.retrofit2:retrofit:2.5.0
    • com.squareup.retrofit2:converter-scalars:2.5.0
    • com.squareup.retrofit2:converter-gson:2.5.0
    • io.reactivex.rxjava2:rxjava:2.2.21
    • io.reactivex.rxjava2:rxandroid:2.1.1
    • io.reactivex.rxjava2:rxkotlin:2.4.0
    • com.jakewharton.rxrelay2:rxrelay:2.1.1
    • com.afollestad.material-dialogs:core:3.3.0
    • com.hannesdorfmann:adapterdelegates4:4.2.0
    • com.hannesdorfmann:adapterdelegates4-kotlin-dsl-layoutcontainer:4.2.0
    • com.daimajia.easing:library:2.0@aar
    • com.daimajia.androidanimations:library:2.3@aar
    • com.github.bumptech.glide:glide:4.11.0
    • com.github.bumptech.glide:compiler:4.11.0
    • com.github.bumptech.glide:okhttp3-integration:4.11.0
    • com.afollestad.material-dialogs:core:3.3.0
    • com.jakewharton.rxbinding2:rxbinding:2.2.0
    • com.github.christophesmet:android_maskable_layout:v1.3.1
    • ru.superjob:kotlin-permissions:1.0.3
    • com.andrognito.flashbar:flashbar:1.0.3
    • com.redmadrobot.inputmask5
    • org.apache.oltu.oauth2:org.apache.oltu.oauth2.client:1.0.1.
  • iOS:

    • AFNetworking
    • Alamofire
    • Firebase
    • FirebaseAnalytics
    • FirebaseAnalyticsInterop
    • FirebaseCore
    • FirebaseCoreDiagnostics
    • FirebaseCoreDiagnosticsInterop
    • FirebaseCrashlytics
    • FirebaseInstallations
    • GoogleAppMeasurement
    • GoogleDataTransport
    • GoogleDataTransportCCTSupport
    • GoogleUtilities
    • Material
    • Motion
    • nanopb
    • netfox
    • NVActivityIndicatorView
    • PromisesObjC
    • RxCocoa
    • RxGesture
    • RxRelay
    • RxSwift
    • SDWebImage
    • SnapKit
    • SocketRocket
    • TSMarkdownParser

    • YandexMobileMetrica.

Адрес расположения команды разработки

Фактический адрес, по которому находится команда разработки: г. Москва, пр-т Вернадского, д. 41.

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

Состав команды, обеспечивающей поддержание жизненного цикла разработки и модернизации:

  • директор проекта — 1 человек,
  • менеджер проекта — 3 человека,
  • владелец продукта — 3 человека,
  • администратор проекта — 1 человек,
  • аналитик — 3 человека,
  • технический писатель — 1 человек,
  • архитектор — 2 человека,
  • дизайнер — 2 человека,
  • разработчик Android — 1 человек,
  • разработчик iOS — 1 человек,
  • разработчик front-end — 4 человека,
  • разработчик Golang — 4 человек,
  • тестировщик — 5 человек,
  • автотестировщик — 2 человека,
  • разработчик Python — 1 человек,
  • разработчик Ruby — 4 человек,
  • разработчик С++ — 4 человека.

Жизненный цикл технической поддержки пользователей

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

Каналы коммуникации

Пользователи могут обращаться в ТП по нескольким официальным каналам:

  • по круглосуточному телефону горячей линии: 8 800 301-25-46,
  • по электронной почте support@camera.rt.ru,
  • через форму обратной связи.

Структура службы ТП

ТП включает в себя несколько уровней. У каждого уровня своя специализация.

Если специалист одного уровня не может решить проблему пользователя своими силами, он передаёт обращение специалисту другого уровня, в соответствии с его специализацией.

Уровни ТП и их специализации:

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

Адрес расположения службы ТП

Специалисты ТП распределены по всей территории России и работают везде, где есть офисы Ростелекома.

Основной фактический адрес расположения службы ТП: г. Москва, пр-т Вернадского, д. 41.

Численность персонала в службе ТП

Техническую поддержку пользователей на постоянной основе осуществляют не менее 1 000 сотрудников.


Последнее обновление: 2022-08-24