Руководство по сопровождению программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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. Сопровождение ПО не предусматривает техническую поддержку АИС. Связано это с небольшой разницей при реализации.

ГОСТ 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«.

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

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

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

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

Источник: