Руководство по сопровождению это

Документация по сопровождению программных средств.

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

Документация
по сопровождению ПС можно разбить на
две группы:

(1)
документация, определяющая строение
программ и структур данных ПС и технологию
их разработки;

(2)
документацию, помогающую вносить
изменения в ПС.

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

  • Внешнее
    описание ПС.

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

  • Для
    каждой программы ПС — описание ее
    модульной структуры, включая внешнюю
    спецификацию каждого включенного в
    нее модуля.

  • Для
    каждого модуля — его спецификация и
    описание его строения.

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

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

Документация
второй группы содержит

  • Руководство
    по сопровождению ПС, которое описывает
    известные проблемы вместе с ПС, описывает,
    какие части системы являются аппаратно-
    и программно-зависимыми, и как развитие
    ПС принято в расчет в его строении
    (конструкции).

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

Тема №9: Обеспечение функциональности, надежности и качества пс. Технологии оценки качества пс.

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

Обеспечение завершенности программного средства.

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

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

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

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

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

Определение понятия

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

Наблюдение за работоспособностью программного средства в России имеет собственный стандарт. Есть международные принципы использования соответствующей операции. Эта документация помогает лучше понять, как реализовывать процесс.

О границах использования

Сопровождение программных продуктов – понятие, которое имеет несколько точек зрения относительно своей применимости:

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

ГОСТ 34.601-90 рассматриваемое понятие предусматривает выполнение работ в соответствие с гарантийными обязательствами (по гарантии), а также послегарантийное обслуживание.

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

Сопровождение – процесс, стандартизированный ISO/IEC 14764:99. Имеет более широкое понятие, чем поддержка. Сопровождением программных продуктов занимаются квалифицированные специалисты. Они лучше разбираются в ошибках и их исправлении, включая скрытые баги.

Структура

Сопровождение программного обеспечения – это характеристики продукта, которые позволяют свести к минимуму изменения:

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

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

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

  1. Линия 0. Информационный центр или «горячая линия». Здесь ведется обработка телефонных клиентских звонков с последующей передачей обращений техническим специалистам.
  2. Линия 1. Работает инженер по сопровождению. Он консультирует клиентов. При необходимости – настраивает софт и устраняет ошибки. Специалист занимается наполнением базы знаний и составлением руководств (мануалов).
  3. Линия 2. Здесь в дело вступает инженер техподдержки. Он отвечает за функциональное сопровождение и проектную деятельность на этапе установки и активации контента непосредственно на устройствах клиента.
  4. Линия 3. Осуществляется сопровождение и проектная деятельность на оборудовании в момент запуск софта.

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

Виды

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

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

Это – основа, на которую опирается весь процесс. Остальные особенности базового обслуживания будут обсуждаться с клиентом в соответствие с его потребностями.

Расширенный тип предусматривает:

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

Остальные задачи обсуждаются индивидуально.

Этапы

Рассматриваемая операция обычно включает в себя несколько этапов:

  1. Подготовка к необходимым исследованиям и действиям.
  2. Анализ имеющихся проблем, возникающих неполадок, ошибок. Здесь же обсуждаются и оцениваются корректировки.
  3. Внесение изменений.
  4. Проверка и приемка контента.

В процессе проведенного комплекса работ имеющийся софт могут перенести на другие устройства заказчиков или снять с реализации. Выше – пример процесса на базе цикла Деминга.

Как быстро освоить направление

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

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

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!

Также, возможно, вам будет интересен курс «Руководитель поддержки пользователей в IT«.

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

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

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

Что является сопровождением ПО

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

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

  1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком, может включать:
    • обучение работе с продуктом и его обслуживание в режиме диспетчерской связи. Иначе — информационно-справочная поддержка функционирования продукта;
    • адаптацию, настройку, изменение и дальнейшую техподдержку экземпляров с учетом особенностей среды пользователя. Речь может идти об обеспечении работоспособности и функционирования экземпляра ПО и БД при первичной интеграции и в случаях изменений в программно-аппаратной среде пользователя (адаптация, переустановки);
    • поддержку работоспособности, профилактику и устранение сбоев в работе пользовательских экземпляров. Данное направление предполагает мониторинг и устранение ошибок и сбоев в работе конкретных пользовательских экземпляров ПО и БД в том числе путем тестирования, а также иными способами и средствами;
    • прочие, обычно индивидуально обусловленные операции, в той или иной мере изначально заложенные разработчиком.
  2. Расширенный тип сопровождения — дополнительно включает некоторую доработку (модификацию) ПО и БД, в частности:
    • модификацию эталонного ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры. Модификация продукта производится в интересах его совершенствования, а загрузка обновленных версий (пакетов обновления) в индивидуальные пользовательские экземпляры ПО и БД вместе с их адаптацией в конкретной программно-аппаратной среде необходимы для доведения обновлений до пользователей;
    • модификацию эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры. Модификация продукта иногда требуется для устранения и предотвращения различных серьезных ошибок и сбоев, до пользователей они доводятся аналогично.

Сразу отметим, что приведенный комплекс операций очерчивает границы сопровождения ПО и БД как теоретической категории. На практике же, в рамках конкретных договоров и техзаданий, сопровождение ПО и БД обычно представлено лишь какой-то частью этих операций, интересных и необходимых конкретному пользователю данного продукта с учетом особенностей его технологии, сервисной политики разработчика, объема потребностей и т. д. Таким образом, любой компонент представляет собой сопровождение ПО и БД как сам по себе, так и в связке с другими компонентами.

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

Раскрытие понятия сопровождения ПО в официальных документах

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

1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком

1.1. Обучение работе с продуктом и его обслуживание в режиме диспетчерской связи.

  • дополнительные требования к программам для ЭВМ и базам данных, сведения о которых включены в реестр российского программного обеспечения (утв. Постановлением Правительства РФ от 23.03.2017 N 325) [1]. Под сопровождением пользователей понимается информационная поддержка (п. 2). Сопровождение пользователей обеспечивается посредством использования телефонной связи и средств электронной почты на русском языке в круглосуточном режиме (п. 16);
  • Приказ Федерального казначейства от 10.10.2018 N 37н [2].

К услугам, связанным с сопровождением, технической поддержкой, обновлением ПО и БД, отнесены, в частности:

  • прием, выполнение и мониторинг выполнения обращений пользователей программного обеспечения;
    • информационно-справочное обслуживание, включая:
    • поддержку и консультацию пользователей программного обеспечения по телефону и электронной почте;
    • ведение и обновление базы данных, содержащей информацию для службы технической поддержки в целях поддержки и консультации пользователей программного обеспечения.
    • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [3].

Поддержка функционирования ПО и БД может включать в себя обучение или работу в режиме диспетчерской связи (п. 6.4.10.1).

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

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [4].

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

1.3. Профилактика и устранение сбоев в работе пользовательских экземпляров.

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [5].

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

Также в рамках сопровождения возможна профилактическая модификация программного продукта после поставки в целях обнаружения и корректировки имеющихся в нем скрытых ошибок для предотвращения явного проявления этих ошибок при эксплуатации данного продукта (п. 4.11).

1.4. Прочие, обычно индивидуально обусловленные операции.

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

  • Приложение № 6 к Приказу Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П [6].

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

2. Расширенный тип сопровождения — дополнительная доработка (модификация) ПО и БД.

2.1. Модификация эталонных ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры.

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [7].

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

  • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [8].

Результат успешного сопровождения ПО и БД, в частности, предусматривает (п. 6.4.10.2):

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

2.2. Модификация эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры.

  • Решение УФАС по Владимирской области от 27.06.2018 N К-1009-02/2017 [9].

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

Состав работ по сопровождению ПО и БД в различных схемах обслуживания и контрактах

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

Законодательство также не лишает стороны договора возможности разбить весь комплекс операций (услуг и работ) по сопровождению ПО и БД на несколько «учетных единиц», т.е. товарных позиций, в отношении каждой из которых будут действовать различные договорно-правовые режимы и цены. Например, такая разбивка распространена при расширенном сопровождении, включающем модификацию ПО и БД, когда действия по его доработке (улучшению и/или индивидуализации функционала, созданию новых или расширению имеющихся БД и т.п.) выделяются в отдельную товарную позицию или даже в отдельный договор. Это бывает оправдано, ведь модификацией произведения признается его переработкой и имеет особый правовой режим, требующий согласования с разработчиком (пп. 9 п. 2 ст. 1270 ГК РФ) [10]. Но с другой стороны, в ряде случаев сопровождение ПО и БД сводится к минимальной техподдержке их работоспособности в той или иной форме при различных сбоях, и тогда товарная позиция по договору является узкой и монолитной.

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

Можно привести следующие примеры из практики. Пример «широкого» содержания сопровождения ПО и БД — Приложение 4 к Письму Комитета финансов Санкт-Петербурга от 30.11.2010 N 01-02/3067 о финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 г. Согласно данному документу работы и услуги по сопровождению программных продуктов включают:

  1. Модификацию макетов программных продуктов, используемых для автоматизированного ведения бюджетного учета.
  2. Оказание консультационных услуг на рабочем месте пользователя.
  3. Восстановление работоспособности модулей программных продуктов автоматизированного ведения бюджетного учета «1С» и «Парус».
  4. Обучение пользователей ведению бюджетного учета с использованием программных продуктов.
  5. Установка программных продуктов… на дополнительные рабочие места, установка дополнительных модулей программных продуктов.
  6. Выгрузка и загрузка данных для децентрализованных бюджетных учреждений.
  7. Выгрузка и загрузка данных для централизующихся бюджетных учреждений.
  8. Установка новых релизов, редакций, конфигураций.
  9. Обновление первичных документов и отчетных форм.

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

Пример «узкого» содержания сопровождения ПО и БД — Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

В рамках судебного спора процитировано положение заключенного между участниками спора договора: «…Исполнитель обязуется оказать услуги по сопровождению прикладного программного обеспечения в объеме одного отчета для одного пользователя. Сопровождение — процесс улучшения (не ведущий к трудозатратам, более описанных в Приложении N 1), оптимизации и устранения дефектов прикладного ПО после передачи в эксплуатацию, обеспечение полноценной функциональности прикладного ПО, консультации пользователей» [12].

Заключение

В настоящей статье рассмотрены правовые и практические аспекты понятия «сопровождение программного обеспечения (программ для ЭВМ и баз данных)».

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

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

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

  1. Постановление Правительства РФ от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» // Собрание законодательства Российской Федерации, 2017, № 14, ст. 2062.
  2. Приказ Казначейства России от 10.10.2018 N 37н «Об утверждении формы и порядка представления информации о потребности в осуществлении централизованных закупок программного обеспечения для ведения бюджетного учета и формирования потребности для осуществления централизованных закупок программного обеспечения для ведения бюджетного учета» // Официальный интернет-портал правовой информации http://www.pravo.gov.ru, 25.12.2018.
  3. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
  4. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  5. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  6. Приказ Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П «Об утверждении нормативных документов филиала федерального государственного бюджетного учреждения «Федеральная кадастровая палата Федеральной службы государственной регистрации, кадастра и картографии» по Москве в сфере информационных технологий».
  7. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  8. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
  9. Решение Управления Федеральной антимонопольной службы по Владимирской области от 27.06.2018 N К-1009-02/2017.
  10. Гражданский кодекс Российской Федерации (часть четвертая) от 18.12.2006 № 230-ФЗ // Российская газета, № 289, 22.12.2006.
  11. Письмо Комитета финансов Правительства Санкт-Петербурга от 30.11.2010 N 01-02/3067 «О финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 году».
  12. Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

Документация на программное обеспечение — это документы, сопровождающие некоторое программное обеспечение (ПО) — программу или программный продукт. Эти документы описывают то, как работает программа и/или то, как её использовать.

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

Типы документации

Существует четыре основных типа документации на ПО:

  • архитектурная/проектная — обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО
  • техническая — документация на код, алгоритмы, интерфейсы, API
  • пользовательская — руководства для конечных пользователей, администраторов системы и другого персонала
  • маркетинговая

Архитектурная/проектная документация

Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос «почему именно так?» Например, в проектном документе программист может описать обоснование того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи, как можно будет выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или пользовательскую документацию, но всё это действительно важно для проекта.

Техническая документация

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

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

Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML. Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.

Пользовательская документация

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

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

Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.

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

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

Маркетинговая документация

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

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

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

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

Документирование программного обеспечения

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

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

Техническое задание

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

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

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

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

Руководство пользователя

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

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

В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор программы (system administrator) управляет использованием программы ординарными пользователями и осуществляет сопровождение программного средства, не связанное с модификацией программ. Например, он может регулировать права доступа к программе между ординарными пользователями, поддерживать связь с поставщиками программы или выполнять определенные действия, чтобы поддерживать программу в рабочем состоянии, если оно включено как часть в другую систему.

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

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

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

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

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

Инструкция по применению программного средства

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

Справочник по применению программного средства

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

Руководство по управлению программным средством

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

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

Руководство программиста

Документация по сопровождению программного средства (system documentation) описывает программное средство с точки зрения ее разработки.

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

Документация по сопровождению программного средства можно разбить на две группы:

1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;

2. документацию, помогающую вносить изменения в программное средство.

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

  • Внешнее описание программного средства (Requirements document).
  • Описание архитектуры программного средства (description of the system architecture), включая внешнюю спецификацию каждой ее программы.
  • Для каждой программы программного средства — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
  • Для каждого модуля — его спецификация и описание его строения (design description).
  • Тексты модулей на выбранном языке программирования (program source code listings).
  • Документы установления достоверности программного средства (validation documents), описывающие, как устанавливалась достоверность каждой программы программного средства и как информация об установлении достоверности связывалась с требованиями к программному средству.

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

Документация второй группы содержит

  • Руководство по сопровождению программного средства (system maintenance guide), которое описывает известные проблемы вместе с программным средством, описывает, какие части системы являются аппаратно- и программно- зависимыми, и как развитие программного средства принято в расчет в его строении (конструкции).
  • Общая проблема сопровождения программного средства — обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда программное средство изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть зафиксированы в базе данных управления конфигурацией.

Процесс управления конфигурацией

Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении ЖЦ ПС для определения состояния (базовой линии) программных объектов в системе, управления их изменениями и выпуском.

Данный процесс состоит из шести работ. Общее число задач по данным работам равно 6.

  1. Подготовка процесса управления конфигурацией — разработка плана управления конфигурацией. Тип выходного результата задачи — план.
  2. Определение конфигурации — Определение схемы обозначения программных объектов и их версий (объектов программной конфигурации) и документации, в которой фиксируется состояние их конфигурации. Тип выходного результата задачи — описание.
  3. Контроль конфигурации — Регистрация заявок на внесение изменений; анализ и оценка изменений; принятие или непринятие заявки; реализация, верификация и выпуск измененного программного объекта; обеспечение аудиторских проверок изменений.
  4. Учет состояний конфигурации — Подготовка протоколов управления конфигурацией и отчетов о состоянии контролируемых программных объектов. Тип выходного результата задачи — протокол, отчет.
  5. Оценка конфигурации — Определение и обеспечение функциональной законченности и физической завершенности программных объектов. Тип выходного результата задачи — протокол, отчет.
  6. Управление выпуском и поставка — Контроль выпуска и поставки программных продуктов и документации.

Источник:

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

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

Определение понятия

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

Наблюдение за работоспособностью программного средства в России имеет собственный стандарт. Есть международные принципы использования соответствующей операции. Эта документация помогает лучше понять, как реализовывать процесс.

О границах использования

Сопровождение программных продуктов – понятие, которое имеет несколько точек зрения относительно своей применимости:

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

ГОСТ 34.601-90 рассматриваемое понятие предусматривает выполнение работ в соответствие с гарантийными обязательствами (по гарантии), а также послегарантийное обслуживание.

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

Сопровождение – процесс, стандартизированный ISO/IEC 14764:99. Имеет более широкое понятие, чем поддержка. Сопровождением программных продуктов занимаются квалифицированные специалисты. Они лучше разбираются в ошибках и их исправлении, включая скрытые баги.

Структура

Сопровождение программного обеспечения – это характеристики продукта, которые позволяют свести к минимуму изменения:

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

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

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

  1. Линия 0. Информационный центр или «горячая линия». Здесь ведется обработка телефонных клиентских звонков с последующей передачей обращений техническим специалистам.
  2. Линия 1. Работает инженер по сопровождению. Он консультирует клиентов. При необходимости – настраивает софт и устраняет ошибки. Специалист занимается наполнением базы знаний и составлением руководств (мануалов).
  3. Линия 2. Здесь в дело вступает инженер техподдержки. Он отвечает за функциональное сопровождение и проектную деятельность на этапе установки и активации контента непосредственно на устройствах клиента.
  4. Линия 3. Осуществляется сопровождение и проектная деятельность на оборудовании в момент запуск софта.

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

Виды

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

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

Это – основа, на которую опирается весь процесс. Остальные особенности базового обслуживания будут обсуждаться с клиентом в соответствие с его потребностями.

Расширенный тип предусматривает:

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

Остальные задачи обсуждаются индивидуально.

Этапы

Рассматриваемая операция обычно включает в себя несколько этапов:

  1. Подготовка к необходимым исследованиям и действиям.
  2. Анализ имеющихся проблем, возникающих неполадок, ошибок. Здесь же обсуждаются и оцениваются корректировки.
  3. Внесение изменений.
  4. Проверка и приемка контента.

В процессе проведенного комплекса работ имеющийся софт могут перенести на другие устройства заказчиков или снять с реализации. Выше – пример процесса на базе цикла Деминга.

Как быстро освоить направление

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

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

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!

Также, возможно, вам будет интересен курс «Руководитель поддержки пользователей в IT«.

Документация по сопровождению программных средств.

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

Документация
по сопровождению ПС можно разбить на
две группы:

(1)
документация, определяющая строение
программ и структур данных ПС и технологию
их разработки;

(2)
документацию, помогающую вносить
изменения в ПС.

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

  • Внешнее
    описание ПС.

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

  • Для
    каждой программы ПС — описание ее
    модульной структуры, включая внешнюю
    спецификацию каждого включенного в
    нее модуля.

  • Для
    каждого модуля — его спецификация и
    описание его строения.

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

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

Документация
второй группы содержит

  • Руководство
    по сопровождению ПС, которое описывает
    известные проблемы вместе с ПС, описывает,
    какие части системы являются аппаратно-
    и программно-зависимыми, и как развитие
    ПС принято в расчет в его строении
    (конструкции).

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

Тема №9: Обеспечение функциональности, надежности и качества пс. Технологии оценки качества пс.

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

Обеспечение завершенности программного средства.

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

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

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

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

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

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

Что является сопровождением ПО

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

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

  1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком, может включать:
    • обучение работе с продуктом и его обслуживание в режиме диспетчерской связи. Иначе — информационно-справочная поддержка функционирования продукта;
    • адаптацию, настройку, изменение и дальнейшую техподдержку экземпляров с учетом особенностей среды пользователя. Речь может идти об обеспечении работоспособности и функционирования экземпляра ПО и БД при первичной интеграции и в случаях изменений в программно-аппаратной среде пользователя (адаптация, переустановки);
    • поддержку работоспособности, профилактику и устранение сбоев в работе пользовательских экземпляров. Данное направление предполагает мониторинг и устранение ошибок и сбоев в работе конкретных пользовательских экземпляров ПО и БД в том числе путем тестирования, а также иными способами и средствами;
    • прочие, обычно индивидуально обусловленные операции, в той или иной мере изначально заложенные разработчиком.
  2. Расширенный тип сопровождения — дополнительно включает некоторую доработку (модификацию) ПО и БД, в частности:
    • модификацию эталонного ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры. Модификация продукта производится в интересах его совершенствования, а загрузка обновленных версий (пакетов обновления) в индивидуальные пользовательские экземпляры ПО и БД вместе с их адаптацией в конкретной программно-аппаратной среде необходимы для доведения обновлений до пользователей;
    • модификацию эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры. Модификация продукта иногда требуется для устранения и предотвращения различных серьезных ошибок и сбоев, до пользователей они доводятся аналогично.

Сразу отметим, что приведенный комплекс операций очерчивает границы сопровождения ПО и БД как теоретической категории. На практике же, в рамках конкретных договоров и техзаданий, сопровождение ПО и БД обычно представлено лишь какой-то частью этих операций, интересных и необходимых конкретному пользователю данного продукта с учетом особенностей его технологии, сервисной политики разработчика, объема потребностей и т. д. Таким образом, любой компонент представляет собой сопровождение ПО и БД как сам по себе, так и в связке с другими компонентами.

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

Раскрытие понятия сопровождения ПО в официальных документах

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

1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком

1.1. Обучение работе с продуктом и его обслуживание в режиме диспетчерской связи.

  • дополнительные требования к программам для ЭВМ и базам данных, сведения о которых включены в реестр российского программного обеспечения (утв. Постановлением Правительства РФ от 23.03.2017 N 325) [1]. Под сопровождением пользователей понимается информационная поддержка (п. 2). Сопровождение пользователей обеспечивается посредством использования телефонной связи и средств электронной почты на русском языке в круглосуточном режиме (п. 16);
  • Приказ Федерального казначейства от 10.10.2018 N 37н [2].

К услугам, связанным с сопровождением, технической поддержкой, обновлением ПО и БД, отнесены, в частности:

  • прием, выполнение и мониторинг выполнения обращений пользователей программного обеспечения;
    • информационно-справочное обслуживание, включая:
    • поддержку и консультацию пользователей программного обеспечения по телефону и электронной почте;
    • ведение и обновление базы данных, содержащей информацию для службы технической поддержки в целях поддержки и консультации пользователей программного обеспечения.
    • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [3].

Поддержка функционирования ПО и БД может включать в себя обучение или работу в режиме диспетчерской связи (п. 6.4.10.1).

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

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [4].

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

1.3. Профилактика и устранение сбоев в работе пользовательских экземпляров.

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [5].

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

Также в рамках сопровождения возможна профилактическая модификация программного продукта после поставки в целях обнаружения и корректировки имеющихся в нем скрытых ошибок для предотвращения явного проявления этих ошибок при эксплуатации данного продукта (п. 4.11).

1.4. Прочие, обычно индивидуально обусловленные операции.

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

  • Приложение № 6 к Приказу Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П [6].

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

2. Расширенный тип сопровождения — дополнительная доработка (модификация) ПО и БД.

2.1. Модификация эталонных ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры.

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [7].

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

  • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [8].

Результат успешного сопровождения ПО и БД, в частности, предусматривает (п. 6.4.10.2):

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

2.2. Модификация эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры.

  • Решение УФАС по Владимирской области от 27.06.2018 N К-1009-02/2017 [9].

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

Состав работ по сопровождению ПО и БД в различных схемах обслуживания и контрактах

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

Законодательство также не лишает стороны договора возможности разбить весь комплекс операций (услуг и работ) по сопровождению ПО и БД на несколько «учетных единиц», т.е. товарных позиций, в отношении каждой из которых будут действовать различные договорно-правовые режимы и цены. Например, такая разбивка распространена при расширенном сопровождении, включающем модификацию ПО и БД, когда действия по его доработке (улучшению и/или индивидуализации функционала, созданию новых или расширению имеющихся БД и т.п.) выделяются в отдельную товарную позицию или даже в отдельный договор. Это бывает оправдано, ведь модификацией произведения признается его переработкой и имеет особый правовой режим, требующий согласования с разработчиком (пп. 9 п. 2 ст. 1270 ГК РФ) [10]. Но с другой стороны, в ряде случаев сопровождение ПО и БД сводится к минимальной техподдержке их работоспособности в той или иной форме при различных сбоях, и тогда товарная позиция по договору является узкой и монолитной.

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

Можно привести следующие примеры из практики. Пример «широкого» содержания сопровождения ПО и БД — Приложение 4 к Письму Комитета финансов Санкт-Петербурга от 30.11.2010 N 01-02/3067 о финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 г. Согласно данному документу работы и услуги по сопровождению программных продуктов включают:

  1. Модификацию макетов программных продуктов, используемых для автоматизированного ведения бюджетного учета.
  2. Оказание консультационных услуг на рабочем месте пользователя.
  3. Восстановление работоспособности модулей программных продуктов автоматизированного ведения бюджетного учета «1С» и «Парус».
  4. Обучение пользователей ведению бюджетного учета с использованием программных продуктов.
  5. Установка программных продуктов… на дополнительные рабочие места, установка дополнительных модулей программных продуктов.
  6. Выгрузка и загрузка данных для децентрализованных бюджетных учреждений.
  7. Выгрузка и загрузка данных для централизующихся бюджетных учреждений.
  8. Установка новых релизов, редакций, конфигураций.
  9. Обновление первичных документов и отчетных форм.

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

Пример «узкого» содержания сопровождения ПО и БД — Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

В рамках судебного спора процитировано положение заключенного между участниками спора договора: «…Исполнитель обязуется оказать услуги по сопровождению прикладного программного обеспечения в объеме одного отчета для одного пользователя. Сопровождение — процесс улучшения (не ведущий к трудозатратам, более описанных в Приложении N 1), оптимизации и устранения дефектов прикладного ПО после передачи в эксплуатацию, обеспечение полноценной функциональности прикладного ПО, консультации пользователей» [12].

Заключение

В настоящей статье рассмотрены правовые и практические аспекты понятия «сопровождение программного обеспечения (программ для ЭВМ и баз данных)».

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

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

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

  1. Постановление Правительства РФ от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» // Собрание законодательства Российской Федерации, 2017, № 14, ст. 2062.
  2. Приказ Казначейства России от 10.10.2018 N 37н «Об утверждении формы и порядка представления информации о потребности в осуществлении централизованных закупок программного обеспечения для ведения бюджетного учета и формирования потребности для осуществления централизованных закупок программного обеспечения для ведения бюджетного учета» // Официальный интернет-портал правовой информации http://www.pravo.gov.ru, 25.12.2018.
  3. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
  4. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  5. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  6. Приказ Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П «Об утверждении нормативных документов филиала федерального государственного бюджетного учреждения «Федеральная кадастровая палата Федеральной службы государственной регистрации, кадастра и картографии» по Москве в сфере информационных технологий».
  7. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  8. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
  9. Решение Управления Федеральной антимонопольной службы по Владимирской области от 27.06.2018 N К-1009-02/2017.
  10. Гражданский кодекс Российской Федерации (часть четвертая) от 18.12.2006 № 230-ФЗ // Российская газета, № 289, 22.12.2006.
  11. Письмо Комитета финансов Правительства Санкт-Петербурга от 30.11.2010 N 01-02/3067 «О финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 году».
  12. Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

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

Определение процесса сопровождения

Под сопровождением программного обеспечения понимают процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию. К счастью, этот процесс достаточно хорошо стандартизован, и открывать Америку для того, чтобы его разработать и внедрить не придется. Упомянем только некоторые основные стандарты:

  • ISO/IEC 14764 (2006, русский перевод стандарта 1999 г. 2002 г.);
  • ISO/IEC 12207 (2008, русский перевод стандарта 2010г.);
  • ISO 20000;
  • SWEBOK (2004 г.);
  • ITIL v3 (2007 г, обновление 2011 г.);
  • COBIT v5 (2012 г.).

Процесс сопровождения является одной из фаз жизненного цикла программного обеспечения, следующей за передачей ПО в эксплуатацию, и завершается выводом его из эксплуатации. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе использования дефекты и недоработки, для добавления новой функциональности, повышения удобства использования (юзабилити) и роста уровня использования ПО. По стандарту ISO/IEC 12207, этот процесс входит в 5 основных процессов жизненного цикла (ЖЦ) ПО: приобретение, поставка, разработка, эксплуатация, сопровождение.

В общем случае процесс сопровождения состоит из следующих задач:

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

Сопровождение и удовлетворенность пользователей

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

127.jpg

Рис. 1. Область удовлетворенности пользователей.

По неоднократным опросам пользователей, они ждут от нового ПО, разработанного и внедренного, в частности, на платформе «1С:Предприятие» следующего:

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

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

Но, чтобы достичь таких результатов, сопровождение должно осуществляться на должном уровне. Ведь в противном случае эту удовлетворенность можно даже уменьшить.

Типы заявок предложений о модификации

Процесс сопровождения состоит из обработки заявок пользователей. Эти заявки целесообразно классифицировать по типам (см. рис. 2).

128.jpg

Рис. 2. Иерархия типов предложения по модификации ПО (по стандарту ГОСТ Р ИСО/МЭК 14764-2002)

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

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

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

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

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

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

Этапы процесса сопровождения

Этапы процесса сопровождения основаны на цикле Деминга PDCA (Plan Do Check Analyze) или «планируй делай проверяй анализируй» (см. рис. 3).

129.jpg

Рис. 3. Общая структура процесса сопровождения (по стандарту ГОСТ Р ИСО/МЭК 14764-2002)

Формирование процесса сопровождения начинается с разработки концепции сопровождения. Такой документ, например, по стандарту ISO/IEC 14764 (Standard for Software Engineering Software Maintenance), должен содержать следующие разделы:

1. Область сопровождения программного средства.

1.1. Типы выполняемого сопровождения.
1.2. Сопровождаемый уровень документов.
1.3. Реакция (чувствительность) на сопровождение
       (определение ожиданий к сопровождению заказчика).
1.4. Обеспечиваемый уровень обучения персонала.
1.5. Обеспечение поставки продукта.
1.6. Организация справочной службы («горячей линии»).

2. Практическое применение (адаптация) данного процесса.

3. Определение организаций (лиц), ответственных за сопровождение.

4. Оценка стоимости сопровождения:

4.1. Проезд до места расположения пользователя.
4.2. Обучение как сопроводителей, так и пользователей.
4.3. СПИ (среда программной инженерии) и СТПС (среда тестирования программного средства) и их ежегодное сопровождение.
4.4. Персонал (зарплата и премии).

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

Стандарт ГОСТ Р ИСО/МЭК 14764-2002 предлагает следующий состав такого плана:

a). Введение:

  1. описание сопровождаемой системы;
  2. определение исходных состояний программного средства;
  3. описание уровня требуемой поддержки;
  4. определение организаций, осуществляющих сопровождение;
  5. описание любых условий (протоколов), согласованных между заказчиком и поставщиками;

b). Концепция сопровождения (уже кратко описанная выше):

  1. описание концепции;
  2. описание уровня поддержки системы;
  3. установление периода поддержки;
  4. адаптация (практическое применение) процесса сопровождения;

c). Организационные работы и работы по сопровождению:

      1. роли и обязанности сопроводителя до поставки программного продукта:

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

     2. роли и обязанности сопроводителя после поставки программного продукта:

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

      3. роль пользователя:

  • приемочные испытания;
  • взаимосвязи (интерфейсы) с другими организациями;

d). Ресурсы:

      1. персонал:

  • состав персонала для конкретного проекта; Структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающуюся бюджетирования, финансового менеджмента и управления человеческими ресурсами в области сопровождения.

      2. программные средства:

  • определение программных средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);

      3. технические средства:

  • определение технических средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);

      4. оборудование (аппаратура):

  • определение требований к оборудованию (аппаратуре) системы (помимо технических средств вычислительной техники);

      5. документы:

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

      6. данные;
      7. другие требования к ресурсам (при необходимости);

e). Процесс (как должна быть выполнена конкретная деятельность):

      1. процесс, выполняемый сопроводителем (приводят общее описание процесса без детализации в плане сопровождения всего процесса);

      2. процесс адаптации (практического применения сопровождения к условиям проекта);

f). Обучение:

      1. определение уровня обучения, необходимого для сопроводителя и пользователей;

g). Протоколы и отчеты по сопровождению:

      1. перечень запросов пользователя на оказание услуг по сопровождению, предложение о модификациях или отчеты о проблемах;
      2. состояния запросов (предложений, отчетов) по категориям;
      3. приоритеты запросов (предложений, отчетов);
      4. контрольные данные, собранные при работах по сопровождению.

Связь сопровождения с эволюцией ПО

Отдельно хочется коснуться связи сопровождения с эволюцией программных систем. В 1969 году Мэнни М. Леман впервые связал деятельность по сопровождению и вопросы эволюции программного обеспечения. Результаты более чем 20-ти летних исследований группы, которой он руководил, привели к формулированию ряда важных положений.
Ключевой результат: деятельность по сопровождению, по сути, представляет собой эволюционную разработку программных систем. Принятию тех или иных решений в процессе сопровождения, помогает понимание того, что происходит с программной системой в процессе ее эксплуатации.

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

Леман вместе с Белади (Lehman and Belady) выделили 3 типа программ.

  1. Программы S-типа, требования к которым могут быть формализованы.
  2. Программы P-типа, которые развиваются итеративно.
  3. Программы E-типа, которые влияют на окружающую среду. Поэтому их нельзя рассматривать изолированно от нее.

На основании этой классификации для программных систем Е-типа постепенно Леманом были сформулированы законы эволюции:

  • (1974) Непрерывное изменение системы E-типа должны непрерывно адаптироваться или они будут все менее удовлетворять потребностям компании.
  • (1974) Увеличение сложности по мере развития систем E-типа их сложность будет возрастать, если не поддерживать их и не уменьшать сложность.
  • (1974) Саморегулирование процесс эволюции систем E-типа саморегулируем, распространение продукта близко к нормальному закону.
  • (1978) Сохранение организационной стабильности средняя скорость развития систем E-типа инвариантна относительного жизненного типа программного продукта.
  • (1978) Сохранение осведомленности поскольку системы E-типа вовлечены во все с ними связанное: разработчиков, продавцов, пользователей, то для достижения полезного развития необходимо поддерживать знание их содержания и поведения различными группами пользователей. Избыточное развитие ухудшает владение системой.
  • (1991) Непрерывное развитие функциональное содержание систем E-типа должно непрерывно расширяться, чтобы обеспечить удовлетворенность пользователей на период жизненного цикла системы.
  • (1996) Ухудшение качества качество систем E-типа будет ухудшаться, если они не будут тщательно сопровождаться и адаптироваться под изменения операционной среды.
  • (1996) Система обратной связи (впервые 1974, формализовано 1996) процессы эволюции систем E-типа представляют собой системы многоуровневой, многоконтурной и охватывающей многих сотрудников обратной связи и должны быть такими, чтобы достигнуть существенных улучшений разумными средствами.

Сопровождение выгодно всем

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

Заказчику

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

Внедренцу — возможность:

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

Вендору

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

Тем, кто этого еще не сделал, необходимо обратить свое внимание на процесс сопровождения программного обеспечения.

Документация по сопровождению программных средств.

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

Документация
по сопровождению ПС можно разбить на
две группы:

(1)
документация, определяющая строение
программ и структур данных ПС и технологию
их разработки;

(2)
документацию, помогающую вносить
изменения в ПС.

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

  • Внешнее
    описание ПС.

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

  • Для
    каждой программы ПС — описание ее
    модульной структуры, включая внешнюю
    спецификацию каждого включенного в
    нее модуля.

  • Для
    каждого модуля — его спецификация и
    описание его строения.

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

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

Документация
второй группы содержит

  • Руководство
    по сопровождению ПС, которое описывает
    известные проблемы вместе с ПС, описывает,
    какие части системы являются аппаратно-
    и программно-зависимыми, и как развитие
    ПС принято в расчет в его строении
    (конструкции).

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

Тема №9: Обеспечение функциональности, надежности и качества пс. Технологии оценки качества пс.

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

Обеспечение завершенности программного средства.

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

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

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

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

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

Определение понятия

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

Наблюдение за работоспособностью программного средства в России имеет собственный стандарт. Есть международные принципы использования соответствующей операции. Эта документация помогает лучше понять, как реализовывать процесс.

О границах использования

Сопровождение программных продуктов – понятие, которое имеет несколько точек зрения относительно своей применимости:

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

ГОСТ 34.601-90 рассматриваемое понятие предусматривает выполнение работ в соответствие с гарантийными обязательствами (по гарантии), а также послегарантийное обслуживание.

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

Сопровождение – процесс, стандартизированный ISO/IEC 14764:99. Имеет более широкое понятие, чем поддержка. Сопровождением программных продуктов занимаются квалифицированные специалисты. Они лучше разбираются в ошибках и их исправлении, включая скрытые баги.

Структура

Сопровождение программного обеспечения – это характеристики продукта, которые позволяют свести к минимуму изменения:

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

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

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

  1. Линия 0. Информационный центр или «горячая линия». Здесь ведется обработка телефонных клиентских звонков с последующей передачей обращений техническим специалистам.
  2. Линия 1. Работает инженер по сопровождению. Он консультирует клиентов. При необходимости – настраивает софт и устраняет ошибки. Специалист занимается наполнением базы знаний и составлением руководств (мануалов).
  3. Линия 2. Здесь в дело вступает инженер техподдержки. Он отвечает за функциональное сопровождение и проектную деятельность на этапе установки и активации контента непосредственно на устройствах клиента.
  4. Линия 3. Осуществляется сопровождение и проектная деятельность на оборудовании в момент запуск софта.

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

Виды

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

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

Это – основа, на которую опирается весь процесс. Остальные особенности базового обслуживания будут обсуждаться с клиентом в соответствие с его потребностями.

Расширенный тип предусматривает:

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

Остальные задачи обсуждаются индивидуально.

Этапы

Рассматриваемая операция обычно включает в себя несколько этапов:

  1. Подготовка к необходимым исследованиям и действиям.
  2. Анализ имеющихся проблем, возникающих неполадок, ошибок. Здесь же обсуждаются и оцениваются корректировки.
  3. Внесение изменений.
  4. Проверка и приемка контента.

В процессе проведенного комплекса работ имеющийся софт могут перенести на другие устройства заказчиков или снять с реализации. Выше – пример процесса на базе цикла Деминга.

Как быстро освоить направление

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

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

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!

Также, возможно, вам будет интересен курс «Руководитель поддержки пользователей в IT«.

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

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

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

Что является сопровождением ПО

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

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

  1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком, может включать:
    • обучение работе с продуктом и его обслуживание в режиме диспетчерской связи. Иначе — информационно-справочная поддержка функционирования продукта;
    • адаптацию, настройку, изменение и дальнейшую техподдержку экземпляров с учетом особенностей среды пользователя. Речь может идти об обеспечении работоспособности и функционирования экземпляра ПО и БД при первичной интеграции и в случаях изменений в программно-аппаратной среде пользователя (адаптация, переустановки);
    • поддержку работоспособности, профилактику и устранение сбоев в работе пользовательских экземпляров. Данное направление предполагает мониторинг и устранение ошибок и сбоев в работе конкретных пользовательских экземпляров ПО и БД в том числе путем тестирования, а также иными способами и средствами;
    • прочие, обычно индивидуально обусловленные операции, в той или иной мере изначально заложенные разработчиком.
  2. Расширенный тип сопровождения — дополнительно включает некоторую доработку (модификацию) ПО и БД, в частности:
    • модификацию эталонного ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры. Модификация продукта производится в интересах его совершенствования, а загрузка обновленных версий (пакетов обновления) в индивидуальные пользовательские экземпляры ПО и БД вместе с их адаптацией в конкретной программно-аппаратной среде необходимы для доведения обновлений до пользователей;
    • модификацию эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры. Модификация продукта иногда требуется для устранения и предотвращения различных серьезных ошибок и сбоев, до пользователей они доводятся аналогично.

Сразу отметим, что приведенный комплекс операций очерчивает границы сопровождения ПО и БД как теоретической категории. На практике же, в рамках конкретных договоров и техзаданий, сопровождение ПО и БД обычно представлено лишь какой-то частью этих операций, интересных и необходимых конкретному пользователю данного продукта с учетом особенностей его технологии, сервисной политики разработчика, объема потребностей и т. д. Таким образом, любой компонент представляет собой сопровождение ПО и БД как сам по себе, так и в связке с другими компонентами.

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

Раскрытие понятия сопровождения ПО в официальных документах

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

1. Базовый тип сопровождения — в объеме штатной поддержки ПО и БД, предусмотренной разработчиком

1.1. Обучение работе с продуктом и его обслуживание в режиме диспетчерской связи.

  • дополнительные требования к программам для ЭВМ и базам данных, сведения о которых включены в реестр российского программного обеспечения (утв. Постановлением Правительства РФ от 23.03.2017 N 325) [1]. Под сопровождением пользователей понимается информационная поддержка (п. 2). Сопровождение пользователей обеспечивается посредством использования телефонной связи и средств электронной почты на русском языке в круглосуточном режиме (п. 16);
  • Приказ Федерального казначейства от 10.10.2018 N 37н [2].

К услугам, связанным с сопровождением, технической поддержкой, обновлением ПО и БД, отнесены, в частности:

  • прием, выполнение и мониторинг выполнения обращений пользователей программного обеспечения;
    • информационно-справочное обслуживание, включая:
    • поддержку и консультацию пользователей программного обеспечения по телефону и электронной почте;
    • ведение и обновление базы данных, содержащей информацию для службы технической поддержки в целях поддержки и консультации пользователей программного обеспечения.
    • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [3].

Поддержка функционирования ПО и БД может включать в себя обучение или работу в режиме диспетчерской связи (п. 6.4.10.1).

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

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [4].

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

1.3. Профилактика и устранение сбоев в работе пользовательских экземпляров.

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [5].

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

Также в рамках сопровождения возможна профилактическая модификация программного продукта после поставки в целях обнаружения и корректировки имеющихся в нем скрытых ошибок для предотвращения явного проявления этих ошибок при эксплуатации данного продукта (п. 4.11).

1.4. Прочие, обычно индивидуально обусловленные операции.

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

  • Приложение № 6 к Приказу Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П [6].

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

2. Расширенный тип сопровождения — дополнительная доработка (модификация) ПО и БД.

2.1. Модификация эталонных ПО и БД с целью развития и встройки обновлений в пользовательские экземпляры.

  • ГОСТ Р ИСО/МЭК 14764-2002 (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) [7].

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

  • ГОСТ Р ИСО/МЭК 12207-2010 (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) [8].

Результат успешного сопровождения ПО и БД, в частности, предусматривает (п. 6.4.10.2):

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

2.2. Модификация эталонного ПО и БД с целью корректной работы и встройки обновлений в пользовательские экземпляры.

  • Решение УФАС по Владимирской области от 27.06.2018 N К-1009-02/2017 [9].

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

Состав работ по сопровождению ПО и БД в различных схемах обслуживания и контрактах

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

Законодательство также не лишает стороны договора возможности разбить весь комплекс операций (услуг и работ) по сопровождению ПО и БД на несколько «учетных единиц», т.е. товарных позиций, в отношении каждой из которых будут действовать различные договорно-правовые режимы и цены. Например, такая разбивка распространена при расширенном сопровождении, включающем модификацию ПО и БД, когда действия по его доработке (улучшению и/или индивидуализации функционала, созданию новых или расширению имеющихся БД и т.п.) выделяются в отдельную товарную позицию или даже в отдельный договор. Это бывает оправдано, ведь модификацией произведения признается его переработкой и имеет особый правовой режим, требующий согласования с разработчиком (пп. 9 п. 2 ст. 1270 ГК РФ) [10]. Но с другой стороны, в ряде случаев сопровождение ПО и БД сводится к минимальной техподдержке их работоспособности в той или иной форме при различных сбоях, и тогда товарная позиция по договору является узкой и монолитной.

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

Можно привести следующие примеры из практики. Пример «широкого» содержания сопровождения ПО и БД — Приложение 4 к Письму Комитета финансов Санкт-Петербурга от 30.11.2010 N 01-02/3067 о финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 г. Согласно данному документу работы и услуги по сопровождению программных продуктов включают:

  1. Модификацию макетов программных продуктов, используемых для автоматизированного ведения бюджетного учета.
  2. Оказание консультационных услуг на рабочем месте пользователя.
  3. Восстановление работоспособности модулей программных продуктов автоматизированного ведения бюджетного учета «1С» и «Парус».
  4. Обучение пользователей ведению бюджетного учета с использованием программных продуктов.
  5. Установка программных продуктов… на дополнительные рабочие места, установка дополнительных модулей программных продуктов.
  6. Выгрузка и загрузка данных для децентрализованных бюджетных учреждений.
  7. Выгрузка и загрузка данных для централизующихся бюджетных учреждений.
  8. Установка новых релизов, редакций, конфигураций.
  9. Обновление первичных документов и отчетных форм.

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

Пример «узкого» содержания сопровождения ПО и БД — Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

В рамках судебного спора процитировано положение заключенного между участниками спора договора: «…Исполнитель обязуется оказать услуги по сопровождению прикладного программного обеспечения в объеме одного отчета для одного пользователя. Сопровождение — процесс улучшения (не ведущий к трудозатратам, более описанных в Приложении N 1), оптимизации и устранения дефектов прикладного ПО после передачи в эксплуатацию, обеспечение полноценной функциональности прикладного ПО, консультации пользователей» [12].

Заключение

В настоящей статье рассмотрены правовые и практические аспекты понятия «сопровождение программного обеспечения (программ для ЭВМ и баз данных)».

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

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

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

  1. Постановление Правительства РФ от 23.03.2017 № 325 «Об утверждении дополнительных требований к программам для электронных вычислительных машин и базам данных, сведения о которых включены в реестр российского программного обеспечения, и внесении изменений в Правила формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных» // Собрание законодательства Российской Федерации, 2017, № 14, ст. 2062.
  2. Приказ Казначейства России от 10.10.2018 N 37н «Об утверждении формы и порядка представления информации о потребности в осуществлении централизованных закупок программного обеспечения для ведения бюджетного учета и формирования потребности для осуществления централизованных закупок программного обеспечения для ведения бюджетного учета» // Официальный интернет-портал правовой информации http://www.pravo.gov.ru, 25.12.2018.
  3. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
  4. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  5. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  6. Приказ Филиала ФГБУ «ФКП Росреестра» по Москве от 16.01.2018 N 010-П «Об утверждении нормативных документов филиала федерального государственного бюджетного учреждения «Федеральная кадастровая палата Федеральной службы государственной регистрации, кадастра и картографии» по Москве в сфере информационных технологий».
  7. ГОСТ Р ИСО/МЭК 14764-2002. Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств (принят и введен в действие Постановлением Госстандарта России от 25.06.2002 N 248-ст) // М.: ИПК Издательство стандартов, 2002.
  8. ГОСТ Р ИСО/МЭК 12207-2010. Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (утв. и введен в действие Приказом Росстандарта от 30.11.2010 N 631-ст) // М.: Стандартинформ, 2011.
  9. Решение Управления Федеральной антимонопольной службы по Владимирской области от 27.06.2018 N К-1009-02/2017.
  10. Гражданский кодекс Российской Федерации (часть четвертая) от 18.12.2006 № 230-ФЗ // Российская газета, № 289, 22.12.2006.
  11. Письмо Комитета финансов Правительства Санкт-Петербурга от 30.11.2010 N 01-02/3067 «О финансировании услуг по сопровождению типовых программных продуктов автоматизированного ведения бюджетного учета в 2011 году».
  12. Решение Арбитражного суда Челябинской области от 27.01.2015 по делу N А76-17104/2014.

В этой статье рассмотрим отдел сопровождения франчайзи (далее – партнеров) в том виде, в котором он должен быть. Будет рассмотрен только тот бизнес, который продает франшизы всем подряд, а не выбирает партнеров тщательно.

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

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


По теме: Готов ли ваш бизнес к созданию франшизы?


За время работы я не раз сталкивался с проблемой сопровождения партнеров. Каждый третий руководитель скажет, что отдел сопровождения – это документальный отдел, который постоянно отвечает на вопросы партнеров, и от них больше ничего не требуется.

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

Факты:

  1. Отдел сопровождения может приносить прибыль. За счет роялти-платежей ежемесячная прибыль компании растет.
  2. Отдел сопровождения прямо пропорционально влияет на количество продаж.
    Если партнеры зарабатывают, то их количество увеличивается. И наоборот, если не зарабатывают, то вероятность хороших продаж франшиз близка к нулю.
  3. Дальнейшие развитие компании зависит от отдела сопровождения.
    Грамотное управление всей сетью для эффективного функционирования  партнеров.

По теме: Причина, по которой ваш бизнес не будет постоянно расти


Команда

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

  • Руководитель отдела;
  • Менеджер по сопровождению.

Дополнительно:

  • Менеджер по закупке;
  • Менеджер по согласованию;
  • Менеджер по маркетингу;
  • HR-менеджер;
  • И другие.

Главное – чтобы в отделе работали талантливые умы, которые могут решить задачу в короткие сроки, без потери качества. И помните: у каждого сотрудника есть своя зона ответственности.

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

Еще команда должна обладать свойством многозадачности. Это свойство в совокупности с компетенциями дает взрывной рост!

Взаимодействие партнера с управляющей компанией (УК)

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

  • план работы;
  • инструкции по открытию ИП или ООО;
  • консультация по налогообложению;
  • бренд-бук;
  • сертификаты (на товары);
  • маркетинг;
  • договоры (трудовые, аренды, поставки и прочее);
  • инструкции (подбор персонала, открытия и прочее);
  • рекомендации по помещению;
  • список оборудования;
  • скрипты по переговорам;
  • анкеты и прочие документы.

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

Предприниматель действует каждую секунду. Это его главное отличие от физического лица.

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

Также будет здорово, если вы запишете видеоинструкции, разбив их на короткие ролики, по 4-5 минут каждый. Видео должно быть снято на профессиональное оборудование. Для наглядности можно сделать видео с инфографикой.

Тематика видеоинструкции. Пример:

  • Приветствие;
  • Подбор персонала;
  • Как закупать товар;
  • Отличие товара А от Б;
  • Пошаговое открытие точки продажи.

Исходя из моего любимого правила Парето, могу с уверенностью сказать, что вы как УК предоставляете партнерам 80% информации. За партнером остается 20% действий – применение теории в практике. Естественно, под чутким контролем менеджера по сопровождению.

Пример из моей практики. Партнер просил сделать рекламу в его городе за счет средств УК. Опираясь на то, что он и так заплатил паушальный взнос и мы должны рекламировать его бизнес. Мы постарались максимально вежливо донести информацию о том, что есть понятие «маркетинговые отчисления», которые у нас отсутствуют, и инвестиции в рекламный бюджет остаются за самим партнером.

Работа с партнерами – самая сложная работа.

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

Все эти платежи клиенты воспринимают как должное и никто не говорит, что у него нет денег, или – что у него в этом месяце не было движения по счету и т.д.

Так в чем же трудность – ежемесячно платить роялти? Ведь роялти платится за право пользование брендом, за консультации, поддержку, маркетинговые акции.

Доводите точную информацию по роялти до партнера.

Еще одним важным документом является регламент.

Примеры из практики.

Внутренний регламент. Работая в туристической компании, у которой было более 90 партнеров, я разработал внутренний регламент, один из пунктов которого гласил: все ответы на вопросы партнеров будут обработаны в течение трех часов с момента отправки вопроса. Менеджер по сопровождению очень разгрузился, и учитывая то, что все вопросы поступали на электронную почту, менеджер начал выполнять свою работу с показателем ответов на полученные письма в 100% случаев. Это удобно для нас и для партнеров. Ситуация win-win.

Также решились дела со «сломанным телефоном». Все вопросы и ответы можно легко отследить через почту менеджера.

Регламент для партнеров. Работая в компании, где была товарная франшиза, мы как УК меняли в одностороннем порядке поставщика товара, т.к. цены у нового поставщика были «вкуснее». Следовательно, это было также выгодно для всех: для партнеров, для поставщика, для нас – чисто морально :)

Общение с партнерами

С партнерами нужно быть настороже. Любые слова могут быть интерпретированы ими в удобной форме. Зачастую – в обратную сторону от сказанного. Поэтому я стараюсь выстроить работу с партнерами письменно, во избежание недопонимания.

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

Быть мягким с людьми – не моя работа. Моя работа – делать их лучше.

Почему «кнут»? Потому что в обязанности руководителя отдела входят такие задачи как решение конфликтных ситуаций, ведение претензионной работы, соблюдение стандартов УК, сбор роялти-платежей. Иногда партнеры бывают неправы, и нужно уметь грамотно донести до них информацию. Конечно, в случаях, когда виновата УК, нужно общаться мягко и доброжелательно. Но исход должен быть один: решение вопроса в короткие сроки.

Партнеры – это лицо вашей компании в разных городах. Они должны оказывать соответствующий сервис, дизайн должен быть выполнен в том же стиле, что и у УК. Для этого должна быть четко и понятно расписана последовательность действий, предоставлены промо-материалы и различные инструкции. Оказывайте хороший сервис, чтобы у партнера не было мысли о смене названия компании и работы под своим брендом. Сделайте так, чтобы партнер был лоялен к вам. Тогда не будет проблем с оплатой роялти.

Процессы внутри УК

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

Пример. Сотрудники отдела сопровождения чем-то занимаются, что-то делают, что-то пишут, но работы не видно. Нет результата их действий, но работа идет постоянно. В одной компании, где я проработал чуть более месяца, директор сказал мне, мол, Руслан, работа у тебя автоматизирована (я вкалывал по 10-12 часов в день), и мы можем посадить на твое место специалиста подешевле. Я подумал, что это странное решение, т.к. чтобы полностью оптимизировать этот отдел, работы предстоит еще очень много. Но руководство не видело «кипящей» жизни отдела и всех подводных камней. После моего ухода мне еще около недели писали-звонили с вопросами, как сделать что-либо. Как итог, при общении с партнерами руководитель компании весь негатив по недоработкам «скинул» на меня и тем самым занял выгодную позицию перед партнерами.

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

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

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

Различие клиентов и партнеров

Руководители компании хотят, чтобы с партнерами через позитив и слаженную работу выстраивались теплые отношения. Это 80% успеха бизнеса! 20% – это закручивание гаек в работе с партнерами через, к сожалению, жесткость.

Клиенты – это конечные пользователи товаров и услуг, оказываемых партнерами. Партнеры представляют УК в своем городе. Партнеры не являются клиентами.

Давайте рассмотрим это подробнее на примере банковской системы, где дополнительные офисы будут выступать в лице партнеров.

Допустим, у банка есть 20 дополнительных офисов. У всех офисов должен быть единый стандарт обслуживания, оформление, фирменная одежда, реклама, бейджи, режим работы, вывеска, тарифы и прочее – все должно быть выполнено в едином стиле. И ни один из офисов не вносит свои правила в работу банка.


По теме: Как мы выстраивали продажи, маркетинг и работу с партнерами


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

Работу отдела сопровождения не видно. Его результат измеряется в полученных роялти-платежах и количестве жалоб, которые доходят до руководства компании.

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

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

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

– Стив Джобс.

Понравилась статья? Поделить с друзьями:
  • Лидерство руководства определение
  • Весы влр 200 инструкция по эксплуатации скачать pdf
  • Роботы lego mindstorms ev3 инструкции постройки роботов
  • Как предупредить руководство об увольнении
  • Назоферон инструкция по применению цена отзывы аналоги цена