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

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

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

• 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-типа представляют собой системы многоуровневой, многоконтурной и охватывающей многих сотрудников обратной связи и должны быть такими, чтобы достигнуть существенных улучшений разумными средствами.

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

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

Заказчику

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

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

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

Вендору

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

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

Комментарии 0