Сопровождение программного обеспечения — это модификация программного обеспечения после поставки. [1]
Согласно стандартному глоссарию IEEE терминологии программной инженерии, обслуживание программного обеспечения относится к процессу модификации и обновления программного обеспечения после его первоначальной разработки и развертывания для исправления ошибок, улучшения производительности или других атрибутов, добавления новых функций для удовлетворения меняющихся требований пользователей или адаптации к изменившейся среде. Важно подчеркнуть, что обслуживание программного обеспечения, таким образом, включает в себя множество действий, которые выходят за рамки простого исправления ошибок. Обслуживание программного обеспечения — это непрерывный процесс, который необходим для долговечности программной системы, для поддержания ее эффективности, адаптивности и релевантности в постоянно меняющемся технологическом ландшафте.
Сопровождение программного обеспечения часто считается менее квалифицированным и менее полезным, чем новая разработка. Таким образом, это обычная цель для аутсорсинга или офшоринга . Обычно команда, разрабатывающая программное обеспечение, отличается от тех, кто будет его поддерживать. У разработчиков нет стимула писать код, который будет легко поддерживать. Программное обеспечение часто поставляется неполным и почти всегда содержит некоторые ошибки, которые группа поддержки должна исправить. Сопровождение программного обеспечения часто изначально включает разработку новых функций, но по мере того, как продукт приближается к концу своего жизненного цикла, обслуживание сокращается до минимума, а затем полностью прекращается перед тем, как продукт будет отозван.
Каждый цикл обслуживания начинается с запроса на изменение, который обычно исходит от конечного пользователя. Этот запрос оценивается, и если решено его реализовать, программист изучает существующий код, чтобы понять, как он работает, прежде чем внедрять изменение. Тестирование для того, чтобы убедиться, что существующая функциональность сохранена и желаемая новая функциональность добавлена, часто составляет большую часть стоимости обслуживания.
Техническое обслуживание программного обеспечения не так хорошо изучено, как другие фазы жизненного цикла программного обеспечения, несмотря на то, что оно составляет большую часть расходов. Понимание не претерпело существенных изменений с 1980-х годов. Техническое обслуживание программного обеспечения можно разделить на несколько типов в зависимости от того, является ли оно профилактическим или реактивным и направлено ли оно на добавление функциональности или сохранение существующей функциональности, последнее обычно происходит в условиях изменившейся среды.
В начале 1970-х годов компании начали выделять поддержку программного обеспечения в отдельную команду инженеров, чтобы освободить команды разработчиков программного обеспечения от задач поддержки. [2] В 1972 году RG Canning опубликовал «The Maintenance 'Iceberg ' », в котором он утверждал, что поддержка программного обеспечения была расширением разработки программного обеспечения с дополнительным вводом: существующей системой. [2] Дисциплина поддержки программного обеспечения с тех пор мало изменилась. [3] Одним из нововведений двадцать первого века стало то, что компании намеренно выпускали неполное программное обеспечение и планировали завершить его после выпуска. Этот тип изменений и другие, которые расширяют функциональность, часто называют эволюцией программного обеспечения вместо поддержки. [3]
Несмотря на тестирование и обеспечение качества , практически все программное обеспечение содержит ошибки , из-за которых система не работает так, как задумано. Послерелизное обслуживание необходимо для устранения этих ошибок, если они обнаружены. [4] Большая часть программного обеспечения представляет собой комбинацию уже существующих коммерческих готовых (COTS) и открытых программных компонентов с индивидуально написанным кодом. COTS и открытое программное обеспечение обычно обновляются с течением времени, что может снизить нагрузку на обслуживание, но изменения в этих программных компонентах необходимо будет скорректировать в конечном продукте. [5] В отличие от разработки программного обеспечения , которая сосредоточена на выполнении определенных требований, обслуживание программного обеспечения обусловлено событиями, такими как запросы пользователей или обнаружение ошибки. [6] Его главная цель — сохранить полезность программного обеспечения, как правило, перед лицом меняющихся требований. [7]
Если рассматривать обслуживание как часть жизненного цикла разработки программного обеспечения , то оно является последней и, как правило, самой продолжительной фазой цикла, [8] [9] составляющей от 80 до 90 процентов стоимости жизненного цикла. [10] Другие модели рассматривают обслуживание отдельно от разработки программного обеспечения, а не как часть жизненного цикла обслуживания программного обеспечения (SMLC). [9] Модели SMLC обычно включают понимание кода, его изменение и повторную проверку. [9]
Часто программное обеспечение поставляется в незавершенном состоянии. Разработчики будут тестировать продукт до тех пор, пока не закончится время или финансирование, поскольку они сталкиваются с меньшими последствиями за несовершенный продукт, чем при превышении времени или бюджета. [11] Переход от команды разработки к команде поддержки часто неэффективен, без списков известных проблем или проверочных тестов, которые команда поддержки, скорее всего, воссоздаст заново. [12] После выпуска члены команды разработки, скорее всего, будут переназначены или иным образом станут недоступны. Группе поддержки потребуются дополнительные ресурсы в течение первого года после выпуска, как для технической поддержки , так и для исправления дефектов, оставшихся от разработки. [11]
Первоначально программное обеспечение может пройти период усовершенствований после выпуска. Новые функции добавляются в соответствии с отзывами пользователей. В какой-то момент компания может решить, что больше невыгодно вносить функциональные улучшения, и ограничить поддержку исправлением ошибок и экстренными обновлениями. Изменения становятся все более сложными и дорогими из-за отсутствия опыта или ухудшения архитектуры из-за старения программного обеспечения . После того, как продукт больше не поддерживается и не получает даже этого ограниченного уровня обновлений, некоторые поставщики будут стремиться извлекать доход из программного обеспечения как можно дольше, даже несмотря на то, что продукт, вероятно, будет все больше избегаться. В конце концов, программное обеспечение будет снято с рынка, хотя оно может продолжать использоваться. В ходе этого процесса программное обеспечение становится устаревшей системой . [13]
Первым шагом в цикле изменений является получение запроса на изменение от клиента и его анализ для подтверждения проблемы и принятия решения о том, следует ли внедрять изменение. [14] Для этого может потребоваться участие нескольких отделов; например, маркетинговая команда может помочь оценить, ожидается ли, что изменение принесет больше бизнеса. [15] Оценка усилий по разработке программного обеспечения является сложной проблемой, в том числе для запросов на изменение обслуживания, [16] но запрос, скорее всего, будет отклонен, если он слишком дорог или невыполним. [17] Если принято решение внедрить запрос, его можно назначить на запланированный релиз и внедрить. [17] Хотя гибкая методология не имеет фазы обслуживания, [18] цикл изменений может быть реализован как спринт Scrum . [19]
Понимание существующего кода является важным шагом перед его изменением. [3] Скорость понимания зависит как от кодовой базы, так и от навыков программиста. [20] Соблюдение соглашений о кодировании, таких как использование четких имен функций и переменных, которые соответствуют их назначению, облегчает понимание. [21] Использование условных операторов цикла только в том случае, если код может быть выполнен более одного раза, и исключение кода, который никогда не будет выполнен, также может повысить понятность. [22] Опытным программистам легче понять, что делает код на высоком уровне. [23] Иногда для ускорения этого процесса используется визуализация программного обеспечения . [24]
Модификация кода может происходить любым способом. С одной стороны, обычно бессистемно применяют быстрое исправление, не имея достаточно времени для обновления документации кода . [25] С другой стороны, жестко структурированное итеративное улучшение может начинаться с изменения документа с требованиями верхнего уровня и распространения изменения на более низкие уровни системы. [26] Модификация часто включает в себя рефакторинг кода (улучшение структуры без изменения функциональности) и реструктуризацию (одновременное улучшение структуры и функциональности). [27] В отличие от коммерческого программного обеспечения, циклы изменений бесплатного и открытого программного обеспечения в значительной степени ограничены кодированием и тестированием с минимальной документацией. Проекты программного обеспечения с открытым исходным кодом вместо этого полагаются на списки рассылки и большое количество участников для понимания кодовой базы и эффективного исправления ошибок. [28]
Дополнительная проблема с обслуживанием заключается в том, что почти каждое изменение кода приводит к появлению новых ошибок или неожиданных волновых эффектов , которые требуют еще одного раунда исправлений. [3] Тестирование может потреблять большую часть ресурсов обслуживания для критически важного для безопасности кода из-за необходимости повторной проверки всего программного обеспечения, если вносятся какие-либо изменения. [29] Повторная проверка может включать обзор кода , регрессионное тестирование с подмножеством модульных тестов , интеграционные тесты и системные тесты . [27] Целью тестирования является проверка того, что предыдущая функциональность сохранена, а новая функциональность добавлена. [30]
Основная цель обслуживания программного обеспечения — обеспечение того, чтобы продукт продолжал соответствовать требованиям удобства использования. Иногда это может означать расширение возможностей продукта за пределы того, что изначально предполагалось. [31]
Согласно спецификации ISO / IEC 14764, обслуживание программного обеспечения можно разделить на четыре типа: [32]
По некоторым оценкам, усовершенствование (последние две категории) составляет около 80 процентов обслуживания программного обеспечения. [36]
Поддерживаемость — это качество программного обеспечения, позволяющее легко модифицировать его, не нарушая существующую функциональность. [32] Согласно спецификации ISO/IEC 14764, деятельность по обеспечению поддерживаемости программного обеспечения перед выпуском считается частью поддержки программного обеспечения. [6] Многие организации по разработке программного обеспечения пренебрегают поддерживаемостью, даже если это увеличит долгосрочные расходы. [37] Технический долг возникает, когда программисты, часто из-за лени или срочности, чтобы уложиться в срок, выбирают быстрые и грязные решения вместо того, чтобы встроить поддерживаемость в свой код. [38] Распространенной причиной является недооценка усилий по разработке программного обеспечения , что приводит к недостаточному выделению ресурсов на разработку. [39] Одним из важных аспектов является наличие большого количества автоматизированных тестов программного обеспечения , которые могут обнаружить, скомпрометирована ли существующая функциональность изменением. [32]
Проблема с удобством обслуживания заключается в том, что многие курсы по программной инженерии не акцентируют на нем внимание и выдают одноразовые задания с четкими и неизменными спецификациями. [40] Курсы по программной инженерии не охватывают такие сложные системы, которые встречаются в реальном мире. [41] Инженеры-разработчики, которые знают, что они не будут отвечать за обслуживание программного обеспечения, не имеют стимула встраивать удобство обслуживания. [3]
Техническое обслуживание часто считается неблагодарной работой для инженеров-программистов , которые, если их назначают на техническое обслуживание, с большей вероятностью увольняются. [42] [43] Зачастую эта работа оплачивается меньше, чем сопоставимая работа в сфере разработки программного обеспечения. [43] Задание часто поручают временным работникам или менее квалифицированному персоналу, [3] [44] хотя инженеры по техническому обслуживанию также обычно старше разработчиков, отчасти потому, что они должны быть знакомы с устаревшими технологиями. [44] В 2008 году около 900 000 из 1,3 миллиона инженеров-программистов и программистов, работающих в Соединенных Штатах, занимались техническим обслуживанием. [45]
Компании создали отдельные команды для обслуживания, что привело к аутсорсингу этой работы другой компании, а к началу двадцать первого века иногда к офшорингу работы в другую страну — будь то в рамках исходной компании или отдельной организации. [46] [10] Типичными источниками аутсорсинга являются развитые страны, такие как США, Великобритания, Япония и Австралия, в то время как пунктами назначения обычно являются страны с более низкой стоимостью труда, такие как Китай, Индия, Россия и Ирландия. [47] Причины офшоринга включают использование преимуществ более низких затрат на рабочую силу, обеспечение круглосуточной поддержки, снижение давления времени на разработчиков и перемещение поддержки ближе к рынку продукта. [48] Недостатки офшоринга включают коммуникационные барьеры в виде таких факторов, как часовой пояс , организационная разобщенность и культурные различия. [10] Несмотря на то, что многие работодатели считают техническое обслуживание низкоквалифицированной работой, а фазу разработки программного обеспечения наиболее подходящей для офшоринга, [10] [49] она требует тесного общения с заказчиком и быстрого реагирования, и то и другое затрудняется этими трудностями в общении. [10]
В программной инженерии термин « унаследованная система» не имеет фиксированного значения, но часто относится к старым системам, которые являются большими, сложными для модификации, а также необходимыми для текущих бизнес-нужд. Часто устаревшие системы написаны на устаревших языках программирования , не имеют документации, имеют ухудшающуюся структуру после многих лет изменений и зависят от экспертов, чтобы поддерживать ее в рабочем состоянии. [50] При работе с этими системами в какой-то момент накапливается так много технического долга, что обслуживание становится непрактичным или экономически невыгодным. [13] Другие варианты включают:
Несмотря на то, что поддержка занимает львиную долю ресурсов разработки программного обеспечения, она является наименее изученной фазой разработки программного обеспечения. [57] [58] Большая часть литературы была сосредоточена на том, как разрабатывать поддерживаемый код с самого начала, при этом меньше внимания уделялось мотивации инженеров сделать поддерживаемость приоритетом. [59] По состоянию на 2020 год [update]автоматизированные решения для рефакторинга кода с целью сокращения усилий по обслуживанию являются активной областью исследований, [60] как и оценка поддерживаемости с помощью машинного обучения . [61]