Сопровождение программного обеспечения - Википедия - Software maintenance

Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) Эта статья имеет нечеткий стиль цитирования. Используемые ссылки можно сделать более ясными с помощью другого или последовательного стиля цитата и сноска. (Сентябрь 2010 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален Найдите источники: «Сопровождение программного обеспечения»  – Новости  · газеты  · книги  · ученый  · JSTOR (Январь 2015) (Узнайте, как и когда удалить этот шаблон сообщения) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

^[9]

Задолженность по обслуживанию

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

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

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

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

и конечно

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

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

Смотрите также

• Отмена приложения
• Журнал поддержки и развития программного обеспечения: исследования и практика
• Долгосрочная поддержка
• Разработка программного обеспечения на основе поиска
• Программная археология
• Сопровождение программного обеспечения
• Разработка программного обеспечения

Рекомендации

^[12]

дальнейшее чтение

• ISO / IEC 14764 IEEE Std 14764-2006 Разработка программного обеспечения - Процессы жизненного цикла программного обеспечения - Сопровождение. 2006. Дои:10.1109 / IEEESTD.2006.235774. ISBN  0-7381-4960-8.
• Пигоски, Томас М. (1996). Практическое сопровождение программного обеспечения. Нью-Йорк: Джон Вили и сыновья. ISBN  978-0-471-17001-3.
• Пигоски, Томас М. Описание эволюции и обслуживания программного обеспечения (версия 0.5). Область знаний SWEBOK.
• Апрель, Алена; Абран, Ален (2008). Управление обслуживанием программного обеспечения. Нью-Йорк: Wiley-IEEE. ISBN  978-0-470-14707-8.
• Гопаласвами Рамеш; Рамеш Бхаттипролу (2006). Сопровождение программного обеспечения: эффективные практики для географически распределенных сред. Нью-Дели: Тата МакГроу-Хилл. ISBN  978-0-07-048345-3.
• Грабб, Пенни; Таканг, Армстронг (2003). Сопровождение программного обеспечения. Нью-Джерси: World Scientific Publishing. ISBN  978-981-238-425-6.
• Lehman, M.M .; Белады, Л.А. (1985). Эволюция программы: процессы изменения программного обеспечения. Лондон: Academic Press Inc. ISBN  0-12-442441-4.
• Пейдж-Джонс, Мейлир (1980). Практическое руководство по проектированию структурированных систем. Нью-Йорк: Yourdon Press. ISBN  0-917072-17-0.

внешняя ссылка

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