Введение
Модификация программного продукта после поставки
Сопровождение программного обеспечения – это модификация программного продукта после поставки. Сопровождение программного обеспечения часто рассматривается как менее квалифицированная и менее престижная работа, чем новая разработка. В связи с этим, оно часто становится объектом аутсорсинга или офшоринга. Обычно команда, разрабатывающая программное обеспечение, отличается от команды, которая будет осуществлять его сопровождение. У разработчиков часто отсутствует мотивация писать код, который легко поддерживать. Программное обеспечение часто поставляется неполным и почти всегда содержит ошибки, которые необходимо исправить команде сопровождения. Сопровождение программного обеспечения часто первоначально включает разработку новой функциональности, но по мере приближения к концу жизненного цикла продукта, оно сводится к минимуму и затем полностью прекращается перед снятием продукта с поддержки. Каждый цикл сопровождения начинается с запроса на изменение, как правило, поступающего от клиента. Этот запрос оценивается, и если принято решение о его реализации, программист изучает существующий код, чтобы понять его работу, прежде чем вносить изменения. Тестирование, направленное на сохранение существующей функциональности и добавление новой, часто составляет основную часть стоимости сопровождения. Сопровождение программного обеспечения изучено не так хорошо, как другие этапы жизненного цикла программного обеспечения, несмотря на то, что оно составляет большую часть затрат. Понимание этой области существенно не изменилось с 1980-х годов. Сопровождение программного обеспечения можно классифицировать на несколько типов в зависимости от того, является ли оно превентивным или реактивным, и направлено ли оно на добавление функциональности или сохранение существующей.
История
В начале 1970-х годов компании стали выделять поддержку программного обеспечения в отдельную команду инженеров, чтобы освободить команды разработки от задач поддержки. В 1972 году Р. Г. Кэннинг опубликовал работу "The Maintenance 'Iceberg", в которой утверждал, что поддержка программного обеспечения – это продолжение разработки программного обеспечения, с дополнительным входным параметром: существующей системой. С тех пор дисциплина поддержки программного обеспечения практически не изменилась. Одним из новшеств XXI века стало намеренное выпуска компаний неполноценного программного обеспечения с последующим планированием его доработки после релиза. Этот тип изменений, а также другие, направленные на расширение функциональности, часто называют эволюцией программного обеспечения, а не поддержкой.
Жизненный цикл программного обеспечения
Несмотря на тестирование и обеспечение качества, практически любое программное обеспечение содержит ошибки, из-за которых система работает не так, как задумано. После выпуска программного обеспечения необходимо его обслуживание для устранения этих ошибок при их обнаружении. Большинство программных продуктов представляют собой комбинацию готовых коммерческих (COTS) и программных компонентов с открытым исходным кодом, дополненных собственным кодом. Компоненты COTS и с открытым исходным кодом обычно обновляются, что может снизить затраты на обслуживание, однако изменения в этих компонентах необходимо учитывать при адаптации конечного продукта. В отличие от разработки программного обеспечения, ориентированной на выполнение заданных требований, обслуживание программного обеспечения определяется событиями – например, запросами пользователей или выявлением ошибок. Его основная цель – сохранение работоспособности программного обеспечения, как правило, в условиях изменяющихся требований. Если рассматривать обслуживание как часть жизненного цикла разработки программного обеспечения, то оно является последней и, как правило, самой продолжительной фазой, требующей около 75% ресурсов, в то время как на начальную фазу разработки приходится лишь 25%. Другие оценки стоимости обслуживания еще выше, достигая 80–90% от общей стоимости жизненного цикла. Существуют также модели, рассматривающие обслуживание программного обеспечения отдельно от его разработки, как часть жизненного цикла обслуживания программного обеспечения (SMLC). Модели SMLC обычно включают анализ кода, его модификацию и повторную валидацию.
Переход от выпуска к техническому обслуживанию до конца срока службы
Часто программное обеспечение поставляется в незавершенном виде. Разработчики тестируют продукт до исчерпания времени или бюджета, поскольку последствия от выпуска несовершенного продукта для них менее значительны, чем срыв сроков или превышение бюджета. Передача от команды разработки команде поддержки часто происходит неэффективно, без списков известных проблем или проверочных тестов, которые команде поддержки, скорее всего, придется воспроизводить. После выпуска члены команды разработки, как правило, переназначаются или становятся недоступными. Команде поддержки потребуется больше ресурсов в течение первого года после выпуска, как для технической поддержки, так и для исправления дефектов, оставшихся от разработки. Первоначально программное обеспечение может пройти этап доработок после выпуска. Новые функции добавляются на основе отзывов пользователей. В какой-то момент компания может решить, что дальнейшее внесение функциональных улучшений невыгодно, и ограничить поддержку исправлением ошибок и срочными обновлениями. Внесение изменений становится все более сложным и дорогим из-за недостатка квалификации или устаревающей архитектуры, вызванной старением программного обеспечения. После прекращения поддержки продукта, даже на минимальном уровне обновлений, некоторые поставщики стремятся извлекать прибыль из программного обеспечения как можно дольше, несмотря на то, что продукт, вероятно, будет все реже использоваться. В конечном итоге программное обеспечение будет снято с продажи, хотя оно может продолжать использоваться. В процессе этого программное обеспечение становится устаревшей системой.
Цикл изменений
Первый шаг в цикле изменений — получение запроса на изменение от клиента и его анализ для подтверждения проблемы и принятия решения о реализации изменения. Это может потребовать участия нескольких отделов; например, команда маркетинга может помочь оценить, приведет ли изменение к увеличению прибыли. Оценка трудозатрат на разработку программного обеспечения — сложная задача, в том числе и для запросов на изменение в рамках технического обслуживания, но запрос, скорее всего, будет отклонен, если он слишком дорог или невыполним. Если принято решение о реализации запроса, его можно включить в запланированный релиз и реализовать. Понимание существующего кода — важный шаг перед его изменением. Скорость понимания зависит как от кодовой базы, так и от квалификации программиста. Следование соглашениям о кодировании, таким как использование понятных имен функций и переменных, соответствующих их назначению, облегчает понимание. Условные циклы следует использовать только в том случае, если код может быть выполнен более одного раза, а удаление кода, который никогда не будет выполнен, также может повысить читаемость. Опытным программистам легче понять, что делает код в целом. Иногда для ускорения этого процесса используется визуализация программного кода. Изменения в коде могут быть внесены любым способом. С одной стороны, распространена практика поспешного применения быстрого исправления без выделения достаточного времени на обновление документации к коду. С другой стороны, строго структурированное итеративное улучшение может начинаться с изменения документа требований верхнего уровня и распространения изменений на более низкие уровни системы. Модификация часто включает рефакторинг кода (улучшение структуры без изменения функциональности) и реструктуризацию (улучшение структуры и функциональности одновременно). В отличие от коммерческого программного обеспечения, циклы изменений в свободном и открытом программном обеспечении в основном ограничиваются кодированием и тестированием с минимальной документацией. Проекты с открытым исходным кодом вместо этого полагаются на рассылки и большое количество участников для понимания кодовой базы и эффективного исправления ошибок. Дополнительная проблема технического обслуживания заключается в том, что почти каждое изменение кода приводит к новым ошибкам или неожиданным последствиям, требующим еще одного раунда исправлений. Тестирование может потребовать большую часть ресурсов для технического обслуживания критически важного для безопасности кода из-за необходимости повторной валидации всего программного обеспечения при любых изменениях. Повторная валидация может включать анализ кода, регрессионное тестирование с использованием подмножества модульных тестов, интеграционные тесты и системные тесты. Цель тестирования — убедиться, что предыдущая функциональность сохранена, а новая функциональность добавлена.
Сохранность
Поддерживаемость — это качество программного обеспечения, обеспечивающее возможность его легкой модификации без нарушения существующей функциональности. Согласно спецификации ISO/IEC 14764, деятельность по обеспечению поддерживаемости программного обеспечения до выпуска считается частью его обслуживания. Многие организации, занимающиеся разработкой программного обеспечения, пренебрегают поддерживаемостью, хотя это в конечном итоге увеличивает долгосрочные затраты. Технический долг возникает, когда программисты, часто из-за лени или срочности в выполнении сроков, выбирают быстрые и некачественные решения вместо того, чтобы закладывать поддерживаемость в свой код. Распространенной причиной является недооценка трудозатрат на разработку программного обеспечения, что приводит к недостаточному выделению ресурсов на разработку. Важным аспектом является наличие большого количества автоматизированных тестов, способных выявить нарушение существующей функциональности при внесении изменений. Сложность поддержания поддерживаемости заключается в том, что многие курсы по разработке программного обеспечения не уделяют ей должного внимания, предлагая разовые задания с четкими и неизменными спецификациями. Эти курсы не рассматривают системы, столь сложные, как те, с которыми приходится сталкиваться в реальном мире. Разработчики, которые не будут отвечать за дальнейшее обслуживание программного обеспечения, не имеют стимула для обеспечения его поддерживаемости.
Рабочая сила
Техническое обслуживание часто рассматривается как неблагодарная работа для инженеров-программистов, которые, будучи назначенными на обслуживание, с большей вероятностью увольнялись. Оно часто оплачивается меньше, чем сопоставимая работа в разработке программного обеспечения. Эта задача часто поручается временным работникам или менее квалифицированному персоналу, хотя инженеры по техническому обслуживанию, как правило, старше разработчиков, отчасти потому, что они должны быть знакомы с устаревшими технологиями. Компании стали создавать отдельные команды для технического обслуживания, что привело к аутсорсингу этой работы другой компании, а к началу двадцать первого века – иногда и к переносу ее в другую часть мира, будь то в рамках исходной компании или в качестве отдельного предприятия. Причины для офшоринга включают использование более низкой стоимости рабочей силы, обеспечение круглосуточной поддержки, снижение временного давления на разработчиков и приближение поддержки к рынку сбыта продукта. К недостаткам офшоринга относятся коммуникационные барьеры, обусловленные такими факторами, как разница во времени, организационная разобщенность и культурные различия. Несмотря на то, что многие работодатели считают техническое обслуживание работой, не требующей высокой квалификации, и этапом разработки программного обеспечения, наиболее подходящим для офшоринга, оно требует тесного взаимодействия с клиентом и оперативного реагирования, что затрудняется этими коммуникационными проблемами. В 2008 году около 900 000 из 1,3 миллиона инженеров-программистов и программистов, работавших в Соединенных Штатах, занимались техническим обслуживанием, и это число продолжало расти, несмотря на увеличение объемов офшоринга.
Исследования
Несмотря на то, что поддержка программного обеспечения поглощает основную часть ресурсов разработки, это наименее изученная стадия жизненного цикла программного обеспечения. Большая часть литературы посвящена разработке изначально поддерживаемого кода, в то время как мотивации инженеров к тому, чтобы поддерживаемость была в приоритете, уделяется меньше внимания. По состоянию на 2020 год, автоматизированные решения для рефакторинга кода с целью снижения усилий по поддержке являются активной областью исследований, как и оценка поддерживаемости с использованием машинного обучения.