Методы настройки и сопровождения системного программного обеспечения компьютерных систем

Обновлено: 03.07.2024

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

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

СОДЕРЖАНИЕ

История

Сопровождение программного обеспечения и эволюция систем впервые были рассмотрены Меиром М. Леманом в 1969 году. В течение двадцати лет его исследования привели к формулировке законов Лемана (Lehman 1997). Основные результаты его исследования заключаются в том, что обслуживание - это действительно эволюционное развитие и что решениям по обслуживанию помогает понимание того, что происходит с системами (и программным обеспечением) с течением времени. Lehman продемонстрировал, что системы продолжают развиваться с течением времени. По мере их развития они становятся более сложными, если не предпринимаются какие-либо действия, такие как рефакторинг кода, для уменьшения сложности. В конце 1970-х годов известное и широко цитируемое исследование, проведенное Линцем и Свансоном, выявило очень высокую долю затрат жизненного цикла , которые затрачивались на техническое обслуживание.

Опрос показал, что около 75% усилий по обслуживанию приходилось на первые два типа, а исправление ошибок занимало около 21%. Многие последующие исследования предполагают аналогичный масштаб проблемы. Исследования показывают, что вклад конечных пользователей имеет решающее значение во время сбора и анализа новых данных о требованиях. Это основная причина любых проблем при разработке и обслуживании программного обеспечения. Сопровождение программного обеспечения важно, поскольку оно потребляет значительную часть общих затрат жизненного цикла, а также невозможность быстрого и надежного изменения программного обеспечения означает, что возможности для бизнеса теряются.

Важность обслуживания программного обеспечения

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

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

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

Планирование обслуживания программного обеспечения

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

Процессы сопровождения программного обеспечения

В этом разделе описаны шесть процессов обслуживания программного обеспечения:

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

Существует ряд процессов, действий и практик, которые уникальны для специалистов по сопровождению, например:

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

Категории обслуживания программного обеспечения

EB Swanson первоначально выделил три категории обслуживания: корректирующее, адаптивное и совершенное. Стандарт IEEE 1219 был заменен в июне 2010 года стандартом P14764 . С тех пор они были обновлены, и ISO / IEC 14764 представляет:

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

Существует также понятие обслуживания перед доставкой / выпуском, которое является всем хорошим, что вы делаете для снижения общей стоимости владения программным обеспечением. Такие вещи, как соблюдение стандартов кодирования, которые включают цели ремонтопригодности программного обеспечения. Управление связью и связностью программного обеспечения. Достижение целей поддержки программного обеспечения (например, SAE JA1004, JA1005 и JA1006). Некоторые академические учреждения проводят исследования для количественной оценки затрат на текущее обслуживание программного обеспечения из-за нехватки ресурсов, таких как проектная документация, обучение и ресурсы для понимания системы / программного обеспечения (умножьте затраты примерно на 1,5-2,0, если нет данных о дизайне) .

Факторы обслуживания

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

Факторы обслуживания	Плюс Диапазон
Специалисты по обслуживанию	35%
Высокий кадровый опыт	34%
Табличные переменные и данные	33%
Низкая сложность базового кода	32%
Проблема 2000 года и специальные поисковые системы	30%
Инструменты реструктуризации кода	29%
Инструменты реинжиниринга	27%
Языки программирования высокого уровня	25%
Инструменты обратного инжиниринга	23%
Инструменты анализа сложности	20%
Инструменты отслеживания дефектов	20%
Специалисты по «массовому обновлению» 2000 года	20%
Инструменты автоматического управления изменениями	18%
Неоплачиваемая сверхурочная работа	18%
Измерения качества	16%
Формальные проверки базового кода	15%
Библиотеки регрессионных тестов	15%
Отличное время отклика	12%
Ежегодное обучение> 10 дней	12%
Высокий управленческий опыт	12%
ПОМОЩЬ автоматизация рабочего стола	12%
Нет модулей, подверженных ошибкам	10%
Он-лайн отчет о дефектах	10%
Измерения производительности	8%
Отличная простота использования	7%
Измерения удовлетворенности пользователей	5%
Высокий командный дух	5%
Сумма	503%

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

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

Факторы обслуживания	Минус Диапазон
Модули, подверженные ошибкам	-50%
Встроенные переменные и данные	-45%
Неопытность персонала	-40%
Высокая сложность кода	-30%
Нет Y2K специальных поисковых систем	-28%
Ручные методы управления изменениями	-27%
Языки программирования низкого уровня	-25%
Нет инструментов отслеживания дефектов	-24%
Нет специалистов по «массовому обновлению» 2000 года	-22%
Плохая простота использования	-18%
Нет качественных измерений	-18%
Нет специалистов по обслуживанию	-18%
Плохое время отклика	-16%
Никаких проверок кода	-15%
Нет библиотек регрессионных тестов	-15%
Нет автоматизации службы поддержки	-15%
Нет онлайн-отчетов о дефектах	-12%
Неопытность в управлении	-15%
Нет инструментов для реструктуризации кода	-10%
Нет ежегодного обучения	-10%
Нет инструментов для реинжиниринга	-10%
Нет инструментов обратного проектирования	-10%
Нет инструментов анализа сложности	-10%
Нет измерений производительности	-7%
Плохой боевой дух команды	-6%
Нет оценок удовлетворенности пользователей	-4%
Никаких неоплачиваемых сверхурочных	0%
Сумма	-500%

Задолженность по содержанию

В документе для 27-й Международной конференции по управлению качеством программного обеспечения в 2019 году Джон Эстдейл ввел термин «задолженность по обслуживанию» для потребностей в обслуживании, вызванных зависимостью реализации от внешних ИТ-факторов, таких как библиотеки, платформы и инструменты, которые устарели. Приложение продолжает работать, и ИТ-отдел забывает об этой теоретической ответственности, сосредотачиваясь на более неотложных требованиях и проблемах в другом месте. Такой долг со временем накапливается, незаметно съедая стоимость программного актива. В конце концов происходит что-то, что делает изменение системы неизбежным.

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

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

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

Наличие соответствующих навыков внутри компании или на рынке.

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

8 мая 2012

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

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

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

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

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

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

устранение сбоев;
улучшение дизайна;
расширение функциональных возможностей;
создание интерфейсов взаимодействия с другими (внешними) системами;
адаптация (например, портирование) для возможности работы на другой (или обновленной) аппаратной платформе, применение новых системных возможностей, функционирование в среде обновленной телекоммуникационной инфраструктуры и т.п.;
миграция унаследованного (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). Введение:

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

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

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

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

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

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

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

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

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

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

d). Ресурсы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заказчику

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

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

Вендору

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

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

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

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

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

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

Принято выделять несколько линий сопровождения:

• 0-я линия (call-center, информационный центр, горячая линия) — обработка телефонных обращений от клиентов, передача обращений техническим специалистам (на 1-ю линию сопровождения);
• 1 -я линия (инженер по сопровождению, инженер технической поддержки, support engineer) — консультация, настройка, устранение ошибок в работе программного обеспечения, наполнение базы знаний, составление руководства пользователей;
• 2-я линия (инженер по сопровождению, инженер технической поддержки, support engineer) — функциональное сопровождение, проектная деятельность на этапе запуска программного обеспечения на оборудовании заказчика;

• 3-я линия (инженер по сопровождению, инженер технической поддержки, support engineer) — системное сопровождение, проектная деятельность на этапе запуска программного обеспечения на оборудовании заказчика.

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

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

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

Существует три вида сопровождения системы:

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

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

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

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

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

Рис.1. Распределение типов сопровождения

Согласно исследованиям, 65% сопровождения связано с выполнением новых требований, 18% отводится на изменения системы с целью адаптации к новому окружению и 17% связано с исправлением ошибок (рис. 1.).

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

Рис.2. Спиральная модель развития ПО

Значительная часть бюджета большинства организаций уходит на сопровождение ПО, а не на само использование программных систем. В 1980-х годах было обнаружено, что во многих организациях по меньшей мере 50% всех средств, потраченных на программирование, идет на развитие уже существующих систем. При этом от 65 до 75% средств общего бюджета расходуется на сопровождение. Так как предприятия заменяют старые системы коммерческим ПО, например программами планирования ресурсов, эти цифры никак не будут уменьшаться. Поэтому можно утверждать, что изменение ПО все еще остается доминирующим в статье затрат организаций на программное обеспечение.

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

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

На рис. 3 показано, как снижается стоимость сопровождения хорошо разработанных систем. Здесь при разработке системы 1 выделено дополнительно $25 000 для облегчения процесса сопровождения. В результате за время эксплуатации системы это помогло сэкономить около $100 000. Из сказанного следует, что увеличение средств на разработку системы пропорционально снизит затраты на ее сопровождение.

Рис.3. Расходы на разработку и сопровождение систем

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

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

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

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

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

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

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

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

Читайте также: