Войти
Обслуживание программного обеспечения в Разработка программного обеспечения - это модификация программного продукта после доставки, чтобы исправить ошибки, улучшить производительность или другие атрибуты.
Распространенное мнение, что обслуживание состоит в том, что оно просто включает исправление дефектов. Однако одно исследование показало, что более 80% усилий по техническому обслуживанию расходуется на некорректирующие действия. Это восприятие поддерживается пользователями, отправляющими отчеты о проблемах, которые на самом деле являются расширением функциональности системы. Более поздние исследования показывают, что доля исправлений ошибок приближается к 21%.
Обслуживание программного обеспечения и эволюция систем впервые была рассмотрена Меиром М. Леманом в 1969 году. В течение двадцати лет его исследования привели к формулировке законов Лемана ( Lehman 1997). Основные результаты его исследования заключаются в том, что обслуживание - это действительно эволюционное развитие и что решениям по обслуживанию помогает понимание того, что происходит с системами (и программным обеспечением) с течением времени. Lehman продемонстрировал, что системы продолжают развиваться с течением времени. По мере их развития они становятся более сложными, если не предпринимаются какие-либо действия, такие как рефакторинг кода, для уменьшения сложности. В конце 1970-х годов известное и широко цитируемое исследование, проведенное Линцем и Суонсоном, выявило очень высокую долю затрат на жизненный цикл, которые затрачивались на техническое обслуживание.
Опрос показал, что около 75% усилий по обслуживанию приходилось на первые два типа, а на исправление ошибок ушло около 21%. Многие последующие исследования предполагают аналогичный масштаб проблемы. Исследования показывают, что вклад конечных пользователей имеет решающее значение во время сбора и анализа новых данных о требованиях. Это основная причина любых проблем во время разработки и обслуживания программного обеспечения. Сопровождение программного обеспечения важно, потому что оно потребляет значительную часть общих затрат жизненного цикла, а также невозможность быстро и надежно изменить программное обеспечение означает, что возможности для бизнеса теряются.
Ключевые вопросы обслуживания программного обеспечения являются как управленческими, так и техническими. Ключевые вопросы управления: согласование с приоритетами клиентов, укомплектование персоналом, какая организация выполняет обслуживание, оценка затрат. Ключевые технические вопросы: ограниченное понимание, анализ воздействия, тестирование, измерение ремонтопригодности.
Обслуживание программного обеспечения - это очень широкая деятельность, которая включает исправление ошибок, расширение возможностей, удаление устаревших возможностей и оптимизацию. Поскольку изменения неизбежны, необходимо разработать механизмы оценки, контроля и внесения изменений.
Таким образом, любая работа по изменению программного обеспечения после его запуска считается работами по техническому обслуживанию. Цель - сохранить ценность программного обеспечения с течением времени. Ценность может быть увеличена за счет расширения клиентской базы, выполнения дополнительных требований, упрощения использования, повышения эффективности и использования новейших технологий. Техническое обслуживание может длиться 20 лет, тогда как разработка может длиться 1-2 года.
Неотъемлемой частью программного обеспечения является обслуживание, которое требует подготовки точного плана обслуживания. во время разработки программного обеспечения. Он должен указать, как пользователи будут запрашивать изменения или сообщать о проблемах. Бюджет должен включать оценку ресурсов и затрат. Новое решение должно быть рассмотрено для разработки каждой новой функции системы и ее целей в области качества. Техническое обслуживание программного обеспечения, которое может длиться 5–6 лет (или даже десятилетий) после процесса разработки, требует наличия эффективного плана, который может охватывать объем обслуживания программного обеспечения, адаптацию процесса после доставки / развертывания, определение того, кто предоставит техническое обслуживание и оценку стоимости жизненного цикла. Выбор надлежащего соблюдения стандартов - сложная задача с самого начала разработки программного обеспечения, которая не имеет особого значения для заинтересованных сторон.
В этом разделе описываются шесть процессов сопровождения программного обеспечения как:
Существует ряд процессов, действий и практик, которые уникальны для специалистов по сопровождению, например:
EB Свонсон первоначально выделил три категории обслуживания: корректирующее, адаптивное и совершенное. Стандарт IEEE 1219 был заменен в июне 2010 года стандартом P14764 . С тех пор они были обновлены, и ISO / IEC 14764 представляет:
также понятие предварительного / предварительного обслуживания, которое является всем хорошим, что вы делаете для снижения общей стоимости владения программным обеспечением. Такие вещи, как соответствие стандартам кодирования, которые включают в себя цели поддержки программного обеспечения. Управление связью и связностью программного обеспечения. Достижение целей поддержки программного обеспечения (например, SAE JA1004, JA1005 и JA1006). Некоторые академические учреждения проводят исследования для количественной оценки затрат на текущее обслуживание программного обеспечения из-за нехватки ресурсов, таких как проектная документация, обучение и ресурсы для понимания системы / программного обеспечения (умножьте затраты примерно на 1,5-2,0, если нет данных о дизайне).
Влияние основных регулировочных факторов на техническое обслуживание (отсортировано в порядке максимального положительного воздействия)
| Факторы технического обслуживания | Plus Range |
|---|---|
| Специалисты по техническому обслуживанию | 35% |
| Большой опыт персонала | 34% |
| Табличные переменные и данные | 33% |
| Низкая сложность базового кода | 32% |
| 2000 год и специальные поисковые системы | 30% |
| Инструменты реструктуризации кода | 29% |
| Инструменты реинжиниринга | 27% |
| Языки программирования высокого уровня | 25% |
| Инструменты обратного проектирования | 23% |
| Инструменты анализа сложности | 20% |
| Инструменты отслеживания дефектов | 20% |
| Специалисты 2000 года по «массовому обновлению» | 20% |
| Инструменты автоматического управления изменениями | 18% |
| Неоплачиваемая сверхурочная работа | 18% |
| Измерения качества | 16% |
| Формальные проверки базового кода | 15% |
| Библиотеки регрессионных тестов | 15% |
| Отличное время отклика | 12% |
| Ежегодное обучение>10 дней | 12% |
| Опыт высшего руководства ence | 12% |
| Автоматизация рабочего стола HELP | 12% |
| Нет модулей, подверженных ошибкам | 10% |
| Отчетность о дефектах в режиме онлайн | 10% |
| Измерения производительности | 8% |
| Превосходная простота использования | 7% |
| Измерения удовлетворенности пользователей | 5% |
| Высокая боевой дух команды | 5% |
| Сумма | 503% |
Не только модули, подверженные ошибкам, доставляют неудобства, но и многие другие факторы также могут ухудшить производительность. Например, очень сложный код спагетти довольно сложно безопасно поддерживать. Очень распространенная ситуация, которая часто снижает производительность, - это отсутствие подходящих инструментов обслуживания, таких как программное обеспечение для отслеживания дефектов, программное обеспечение для управления изменениями и программное обеспечение библиотеки тестов. Ниже описаны некоторые факторы и диапазон их влияния на обслуживание программного обеспечения.
Влияние ключевых поправочных факторов на обслуживание (отсортировано в порядке максимального негативного воздействия)
| Факторы обслуживания | Минус диапазон |
|---|---|
| Модули, подверженные ошибкам | -50% |
| Встроенные переменные и данные | -45% |
| Неопытность персонала | -40% |
| Высокая сложность кода | -30% |
| Нет Y2K специальных поисковых систем | -28% |
| Ручные методы управления изменениями | -27% |
| Языки программирования низкого уровня | -25% |
| Без дефектов инструменты отслеживания | -24% |
| Нет специалистов по «массовому обновлению» 2000 года | -22% |
| Плохая простота использования | -18% |
| Нет измерения качества | -18% |
| Нет специалистов по обслуживанию | -18% |
| Низкое время отклика | -16% |
| Проверка кода не выполняется | -15% |
| Нет библиотек регрессионных тестов | -15% |
| Нет автоматизации службы поддержки | -15% |
| Нет отчетов о дефектах в режиме онлайн | -12% |
| Отсутствие опыта в управлении | -15% |
| Отсутствие инструментов реструктуризации кода | -10% |
| Отсутствие ежегодного обучения | -10 % |
| Нет реенги инструменты разработки | -10% |
| Нет инструментов обратного проектирования | -10% |
| Нет инструментов анализа сложности | -10% |
| Нет измерений производительности | -7% |
| Низкий моральный дух команды | -6% |
| Нет оценок удовлетворенности пользователей | -4% |
| Нет неоплачиваемых сверхурочных | 0% |
| Сумма | -500% |
В докладе на 27-й Международной конференции по управлению качеством программного обеспечения в 2019 году Джон Эстдейл ввел термин «обслуживание задолженность »для обслуживания потребностей, вызванных зависимостью реализации от внешних ИТ-факторов, таких как библиотеки, платформы и инструменты, которые устарели. Приложение продолжает работать, и ИТ-отдел забывает об этой теоретической ответственности, сосредотачиваясь на более неотложных требованиях и проблемах в другом месте. Такой долг со временем накапливается, незаметно съедая стоимость программного актива. В конце концов происходит что-то, что делает изменение системы неизбежным.
После этого владелец может обнаружить, что система больше не может быть изменена - ее буквально невозможно поддерживать. Менее драматично, техническое обслуживание может занять слишком много времени или слишком дорого для решения бизнес-проблемы, и необходимо найти альтернативное решение. Программное обеспечение внезапно упало до 0 фунтов стерлингов.
Estdale определяет «долг обслуживания» как разрыв между текущим состоянием реализации приложения и идеальным, с использованием только функциональных возможностей внешних компонентов, которые полностью поддерживаются и поддерживаются. Этот долг часто скрывается или не признается. Общая ремонтопригодность приложения зависит от постоянной доступности всех видов компонентов от других поставщиков, включая:
и, конечно,
Полное исчезновение компонента может сделать приложение невозможным для восстановления или неизбежно невозможным поддерживать его.
