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

Из Википедии, бесплатной энциклопедии
Часть серии о
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и своды знаний
Глоссарии
Контуры

Сопровождение программного обеспечения — это модификация программного продукта после поставки.

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

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

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

История [ править ]

В начале 1970-х годов компании начали выделять на обслуживание программного обеспечения собственную команду инженеров, чтобы освободить команды разработчиков программного обеспечения от задач поддержки. [1] В 1972 году Р.Г. Каннинг опубликовал книгу «Сопровождение «Айсберга » , в которой он утверждал, что сопровождение программного обеспечения является продолжением разработки программного обеспечения с дополнительным входом: существующей системой. [1] Дисциплина обслуживания программного обеспечения с тех пор мало изменилась. [2] Одной из инноваций двадцать первого века стали компании, намеренно выпускающие неполное программное обеспечение и планирующие завершить его после выпуска. Этот тип изменений и другие, расширяющие функциональность, часто называют эволюцией программного обеспечения , а не его обслуживанием. [2]

Жизненный цикл программного обеспечения [ править ]

Диаграмма традиционного жизненного цикла разработки программного обеспечения с 1988 года.

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

Если рассматривать обслуживание как часть жизненного цикла разработки программного обеспечения , то оно является последней и, как правило, самой продолжительной фазой цикла. [7] [8] Содержит около 75 процентов ресурсов, и только 25 процентов идут на начальную стадию разработки. [9] Другие оценки стоимости обслуживания еще выше и составляют от 80 до 90 процентов стоимости жизненного цикла. [10] Другие модели рассматривают обслуживание отдельно от разработки программного обеспечения, а не как часть жизненного цикла обслуживания программного обеспечения (SMLC). [8] Модели SMLC обычно включают понимание кода, его изменение и повторную проверку. [8]

срока службы Переход от выпуска к сопровождению до окончания

Схема, показывающая этапы прекращения использования программного обеспечения

Зачастую программное обеспечение поставляется в неполном состоянии. Разработчики будут тестировать продукт до тех пор, пока не закончится время или финансирование, потому что из-за несовершенства продукта они сталкиваются с меньшими последствиями, чем из-за превышения времени или бюджета. [11] Переход от группы разработки к команде сопровождения часто бывает неэффективным без списков известных проблем или проверочных тестов, которые группа сопровождения, скорее всего, воссоздаст. [12] После выпуска члены команды разработчиков, скорее всего, будут переназначены или иным образом станут недоступными. Группе сопровождения потребуются дополнительные ресурсы в течение первого года после выпуска, как для технической поддержки , так и для исправления дефектов, оставшихся после разработки. [11]

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

Цикл смены [ править ]

Первым шагом в цикле изменений является получение запроса на изменение от клиента и его анализ для подтверждения проблемы и принятия решения о необходимости внедрения изменения. [14] Это может потребовать участия нескольких отделов; например, команда маркетинга может помочь оценить, приведет ли изменение к увеличению бизнеса. [15] Оценка усилий по разработке программного обеспечения является сложной проблемой, в том числе для запросов на изменения в обслуживании, [16] но запрос, скорее всего, будет отклонен, если он слишком дорог или неосуществим. [17] Если принято решение реализовать запрос, его можно отнести к запланированному выпуску и реализовать. [17]

Понимание существующего кода является важным шагом перед его изменением. [2] Скорость понимания зависит как от базы кода, так и от навыков программиста. [18] Соблюдение соглашений по кодированию, таких как использование понятных имен функций и переменных, соответствующих их назначению, облегчает понимание. [19] Использование операторов условного цикла только в том случае, если код может выполняться более одного раза, а также исключение кода, который никогда не будет выполняться, также может повысить понятность. [20] Опытным программистам легче понять, что делает код на высоком уровне. [21] Программная визуализация иногда используется для ускорения этого процесса. [22]

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

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

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

Основная цель обслуживания программного обеспечения — гарантировать, что продукт продолжает соответствовать требованиям удобства использования. Иногда это может означать расширение возможностей продукта за пределы первоначально запланированного. [29]

Согласно спецификации ISO / IEC 14764, обслуживание программного обеспечения можно разделить на четыре типа: [30]

  • Корректирующее обслуживание : модификация программного обеспечения для исправления ошибки или другого несоответствия требованиям, о которых обычно сообщает клиент. [30] [31]
  • Профилактическое обслуживание : перспективная модификация программного продукта после поставки, чтобы гарантировать, что он продолжает соответствовать требованиям или устранить проблемы, которые еще не проявились. [32] [30] Этот тип обслуживания особенно выполняется для систем, от которых требуется высокая безопасность или доступность. [32] Обновление программного обеспечения — это одна из форм профилактического обслуживания, направленная на очистку состояния и предотвращение будущих проблем. [32]
  • Адаптивное обслуживание: модификация программного продукта, выполняемая после поставки, чтобы сохранить возможность использования программного продукта в изменившейся или изменяющейся среде. [30] [32]
  • Совершенное обслуживание: улучшение программного продукта после поставки для улучшения таких качеств, как удобство использования , эффективность обработки и удобство сопровождения . [32] [33] Совершенное обслуживание необходимо, если выполняются другие виды обслуживания, поскольку в противном случае модификация существующей базы кода увеличит сложность и приведет к ухудшению существующей структуры. [33] Полное обслуживание может включать в себя переписывание документации , рефакторинг кода и настройку производительности. [32]

По некоторым оценкам, усовершенствование (последние две категории) составляет около 80 процентов обслуживания программного обеспечения. [34]

Ремонтопригодность [ править ]

Основная статья: Ремонтопригодность

Ремонтопригодность — это качество программного обеспечения, позволяющее легко модифицировать его, не нарушая существующие функциональные возможности. [30] Согласно спецификации ISO/IEC 14764, деятельность по обеспечению удобства сопровождения программного обеспечения до его выпуска считается частью обслуживания программного обеспечения. [5] Многие организации, занимающиеся разработкой программного обеспечения, пренебрегают удобством сопровождения, даже несмотря на то, что это приведет к увеличению долгосрочных затрат. [35] Технический долг возникает, когда программисты, часто из-за лени или необходимости уложиться в сроки, выбирают быстрые и грязные решения вместо того, чтобы встроить в свой код удобство сопровождения. [36] Распространенной причиной является недооценка усилий по разработке программного обеспечения , что приводит к недостаточности ресурсов, выделяемых на разработку. [37] Одним из важных аспектов является наличие большого количества автоматизированных тестов программного обеспечения , которые могут определить, нарушена ли существующая функциональность из-за изменений. [30]

Проблема с удобством сопровождения заключается в том, что многие курсы по разработке программного обеспечения не уделяют этому особого внимания и дают одноразовые задания с четкими и неизменными спецификациями. [38] Курсы по разработке программного обеспечения не охватывают столь сложные системы, как это происходит в реальном мире. [39] Инженеры-разработчики, которые знают, что они не будут нести ответственность за поддержку программного обеспечения, не имеют стимула повышать удобство сопровождения. [2]

Рабочая сила [ править ]

Техническое обслуживание часто считается неблагодарной работой для инженеров-программистов , которые, если им поручили обслуживание, с большей вероятностью уволятся. [40] [41] Зачастую за него платят меньше, чем за аналогичную работу в сфере разработки программного обеспечения. [41] Эта задача часто поручается временным работникам или менее квалифицированному персоналу. [2] [42] хотя инженеры по техническому обслуживанию обычно старше разработчиков, отчасти потому, что они должны быть знакомы с устаревшими технологиями. [42] Компании создали отдельные команды для технического обслуживания, что привело к передаче этой работы другой компании, а на рубеже XXI века иногда к переносу ее в другую часть мира — будь то в рамках исходной компании или отдельной компании. сущность. [43] [10] Причины оффшоринга включают использование преимуществ более низких затрат на рабочую силу, обеспечение круглосуточной поддержки, сокращение временных ограничений для разработчиков и перемещение поддержки ближе к рынку продукта. [44] К недостаткам оффшоринга относятся коммуникационные барьеры в виде таких факторов, как часовой пояс , организационная разобщенность и культурные различия. [10] Несмотря на то, что многие работодатели рассматривают возможность обслуживания низкоквалифицированной работы и этап разработки программного обеспечения, наиболее подходящий для перевода на офшоринг, [10] [45] это требует тесного общения с клиентом и быстрого реагирования, и то, и другое затрудняется этими трудностями в общении. [10] В 2008 году около 900 000 из 1,3 миллиона инженеров-программистов и программистов, работающих в США, занимались техническим обслуживанием, и это число росло, несмотря на увеличение оффшоринга. [46]

Альтернативы техническому обслуживанию [ править ]

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

  • Заморозка — больше не работайте в устаревшей системе. [48]
  • Передача функций устаревшей системы другой компании, особенно если это не считается основной бизнес-функцией. [48]
  • Отказ от существующей устаревшей системы и переработка нового приложения с нуля для достижения той же цели, что и устаревшая система. [48]
  • Обертывание устаревшего приложения в уровень абстракции для упрощения устаревших интерфейсов. [48]
  • Миграция устаревшей системы на новую платформу, которая может снизить затраты на разработку нового программного обеспечения за счет повторного использования реализации, дизайна, спецификаций и требований устаревшей системы. [49]

Исследования [ править ]

Несмотря на то, что на разработку программного обеспечения уходит львиная доля ресурсов, сопровождение является наименее изученным этапом разработки программного обеспечения. [50] [51] Большая часть литературы с самого начала фокусируется на том, как разрабатывать поддерживаемый код, уделяя меньше внимания мотивации инженеров сделать удобство сопровождения приоритетом. [52] По состоянию на 2020 год Автоматизированные решения для рефакторинга кода с целью сокращения затрат на обслуживание являются активной областью исследований, [53] как и помощью машинного обучения . улучшенная оценка ремонтопригодности с [54]

Ссылки [ править ]

  1. ^ Перейти обратно: а б Трипати и Найк 2014 , с. 25.
  2. ^ Перейти обратно: а б с д Это ж Оффатт, Джефф (январь 2018 г.). «Обзор сопровождения и развития программного обеспечения» . Университета Джорджа Мейсона Факультет компьютерных наук . Проверено 5 мая 2024 г.
  3. ^ Трипатия и Найк 2014 , с. 4.
  4. ^ Трипати и Найк 2014 , стр. 5–6.
  5. ^ Перейти обратно: а б Трипати и Найк 2014 , с. 26.
  6. ^ Мадхусудхан и др. 2017 , с. 761.
  7. ^ Варга 2018 , с. 3.
  8. ^ Перейти обратно: а б с Трипати и Найк 2014 , с. 7.
  9. ^ Варга 2018 , с. 6.
  10. ^ Перейти обратно: а б с д Это Ульзиит и др. 2015 , с. 764
  11. ^ Перейти обратно: а б Райфер 2012 , с. 22.
  12. ^ Райфер 2012 , с. 21.
  13. ^ Перейти обратно: а б Трипати и Найк 2014 , с. 89.
  14. ^ Мадхусудхан и др. 2017 , с. 763.
  15. ^ Трипатия и Найк 2014 , с. 120.
  16. ^ Мадхусудхан и др. 2017 , с. 762.
  17. ^ Перейти обратно: а б Трипати и Найк 2014 , с. 123.
  18. ^ Трипатия и Найк 2014 , с. 296.
  19. ^ Трипати и Найк 2014 , стр. 296–297.
  20. ^ Трипатия и Найк 2014 , с. 309.
  21. ^ Трипатия и Найк 2014 , с. 297.
  22. ^ Трипати и Найк 2014 , стр. 318–319.
  23. ^ Трипати и Найк 2014 , стр. 85–86.
  24. ^ Трипатия и Найк 2014 , с. 86.
  25. ^ Перейти обратно: а б Трипати и Найк 2014 , с. 94.
  26. ^ Трипатия и Найк 2014 , с. 59.
  27. ^ Райфер 2012 , с. 5.
  28. ^ Трипатия и Найк 2014 , с. 98.
  29. ^ Варга 2018 , с. 4.
  30. ^ Перейти обратно: а б с д Это ж Варга 2018 , с. 5.
  31. ^ Трипати и Найк 2014 , стр. 26–27.
  32. ^ Перейти обратно: а б с д Это ж Трипати и Найк 2014 , с. 27.
  33. ^ Перейти обратно: а б Варга 2018 , стр. 5–6.
  34. ^ Варга 2018 , с. 5 сн 4.
  35. ^ Варга 2018 , с. 12.
  36. ^ Варга 2018 , стр. 6–7.
  37. ^ Варга 2018 , с. 7.
  38. ^ Варга 2018 , стр. 7–8.
  39. ^ Варга 2018 , с. 9.
  40. ^ Мадхусудхан и др. 2017 , с. 764.
  41. ^ Перейти обратно: а б Райфер 2012 , с. 7.
  42. ^ Перейти обратно: а б Райфер 2012 , с. 8-й.
  43. ^ Рахман и др. 2024 , с. 1.
  44. ^ Ульзиит и др. 2015 , с. 763.
  45. ^ Райфер 2012 , с. 2.
  46. ^ Райфер 2012 , с. 1.
  47. ^ Трипати и Найк 2014 , стр. 187–188.
  48. ^ Перейти обратно: а б с д Трипати и Найк 2014 , с. 188.
  49. ^ Трипати и Найк 2014 , стр. 188–189.
  50. ^ Мадхусудхан и др. 2017 , с. 759.
  51. ^ Ульзиит и др. 2015 , с. 766
  52. ^ Райфер 2012 , стр. 4–5.
  53. ^ Бакайс и Альшаеб 2020 , с. 459.
  54. ^ Алсолай и Ропер 2020 , с. 106214.

Источники [ править ]

  • Алсолаи, Хадил; Ропер, Марк (2020). «Систематический обзор литературы по методам машинного обучения для прогнозирования ремонтопригодности программного обеспечения». Информационные и программные технологии . 119 : 106214. doi : 10.1016/j.infsof.2019.106214 .
  • Бакайс, Абдулрахман Ахмед Бобакр; Альшаиб, Мохаммед (2020). «Автоматический рефакторинг программного обеспечения: систематический обзор литературы». Журнал качества программного обеспечения . 28 (2): 459–502. дои : 10.1007/s11219-019-09477-y .
  • Мадхусудхан, В.; Сума, В.; Рао, Джавахар Дж. (2017). Сопровождение программного обеспечения: с точки зрения усилий и затрат . Материалы Международной конференции по инженерии данных и коммуникационным технологиям. Спрингер. стр. 759–768. ISBN  978-981-10-1678-3 .
  • Рахман, Ханиф Ур; да Силва, Альберто Родригес; Альзаид, Асаад; Раза, Муштак (2024). «Систематический обзор литературы по решениям о переносе обслуживания программного обеспечения». Информационные и программные технологии . 172 : 107475. doi : 10.1016/j.infsof.2024.107475 .
  • Райфер, Дональд Дж. (2012). Рецепты успешного обслуживания программного обеспечения . ЦРК Пресс. ISBN  978-1-4398-5167-8 .
  • Трипати, Приядарши; Наик, Кширасагар (2014). Эволюция и сопровождение программного обеспечения: подход практикующего специалиста . Джон Уайли и сыновья. ISBN  978-0-470-60341-3 .
  • Улзиит, Баярбуян; Варрайх, Зишан Ахтар; Генсель, Сигдем; Петерсен, Кай (2015). «Концептуальная основа проблем и решений для управления глобальным обслуживанием программного обеспечения». Журнал программного обеспечения: эволюция и процесс . 27 (10): 763–792. дои : 10.1002/смр.1720 .
  • Варга, Эрвин (2018). Разгадка сопровождения и эволюции программного обеспечения: нестандартное мышление . Спрингер. ISBN  978-3-319-71303-8 .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_maintenance&oldid=1222992826"