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