 | Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) ( Узнайте, как и когда удалить этот шаблон сообщения )
|
| Разработка программного обеспечения |
|---|
Сопровождение программного обеспечения в программной инженерии - это модификация программного продукта после поставки для исправления ошибок, повышения производительности или других характеристик. [1]
Распространенное мнение о техническом обслуживании состоит в том, что оно просто включает в себя устранение дефектов . Однако одно исследование показало, что более 80% усилий по техническому обслуживанию тратится на некорректирующие действия. [2] Это восприятие закреплено пользователями, отправляющими отчеты о проблемах, которые на самом деле являются расширением функциональности системы. [ необходима цитата ] Более поздние исследования показывают, что доля исправлений ошибок приближается к 21%. [3]
История [ править ]
Сопровождение программного обеспечения и эволюция систем были впервые рассмотрены Меиром М. Леманом в 1969 году. В течение двадцати лет его исследования привели к формулировке законов Лемана (Lehman 1997). Основные результаты его исследования заключаются в том, что обслуживание - это действительно эволюционное развитие и что решениям по обслуживанию помогает понимание того, что происходит с системами (и программным обеспечением) с течением времени. Lehman продемонстрировал, что системы продолжают развиваться с течением времени. По мере их развития они становятся более сложными, если не предпринимаются какие-либо действия, такие как рефакторинг кода, для уменьшения сложности. В конце 1970-х годов известное и широко цитируемое исследование Линца и Свансона выявило очень высокую долю затрат в течение жизненного цикла. которые расходуются на техническое обслуживание.
Опрос показал, что около 75% усилий по обслуживанию приходилось на первые два типа, а на исправление ошибок ушло около 21%. Многие последующие исследования предполагают аналогичный масштаб проблемы. Исследования показывают, что вклад конечных пользователей имеет решающее значение во время сбора и анализа новых данных о требованиях. Это основная причина любых проблем при разработке и обслуживании программного обеспечения. Сопровождение программного обеспечения важно, поскольку оно потребляет значительную часть общих затрат жизненного цикла, а также невозможность быстро и надежно изменить программное обеспечение означает, что возможности для бизнеса упущены.[4] [5] [6]
Важность обслуживания программного обеспечения [ править ]
Ключевые вопросы обслуживания программного обеспечения являются как управленческими, так и техническими. Ключевые вопросы управления: согласование с приоритетами клиентов, укомплектование персоналом, какая организация выполняет обслуживание, оценка затрат. Ключевые технические вопросы: ограниченное понимание, анализ воздействия , тестирование, измерение ремонтопригодности.
Обслуживание программного обеспечения - это очень широкий вид деятельности, который включает исправление ошибок, расширение возможностей, удаление устаревших возможностей и оптимизацию. Поскольку изменения неизбежны, необходимо разработать механизмы оценки, контроля и внесения изменений.
Таким образом, любая работа по изменению программного обеспечения после его ввода в эксплуатацию считается работами по техническому обслуживанию. Цель состоит в том, чтобы сохранить ценность программного обеспечения с течением времени. Ценность может быть увеличена за счет расширения клиентской базы, удовлетворения дополнительных требований, упрощения использования, повышения эффективности и использования новейших технологий. Техническое обслуживание может охватывать в течение 20 лет, [ править ] в то время как развитие может быть 1-2 лет. [ необходима цитата ]
Планирование обслуживания программного обеспечения [ править ]
Неотъемлемой частью программного обеспечения является обслуживание, которое требует составления точного плана обслуживания во время разработки программного обеспечения. В нем следует указать, как пользователи будут запрашивать изменения или сообщать о проблемах. Бюджет должен включать оценку ресурсов и затрат. При разработке каждой новой функции системы и ее целей в области качества необходимо принимать новое решение. Обслуживание программного обеспечения, которое может длиться 5–6 лет (или даже десятилетий) после процесса разработки, требует эффективного плана, который может охватывать объем обслуживания программного обеспечения, адаптацию процесса после доставки / развертывания, определение того, кто предоставит техническое обслуживание и оценку стоимости жизненного цикла.Выбор надлежащего соблюдения стандартов - сложная задача с самого начала разработки программного обеспечения, которая не имеет особого значения для заинтересованных сторон.
Процессы обслуживания программного обеспечения [ править ]
В этом разделе описаны шесть процессов обслуживания программного обеспечения:
- Процесс внедрения включает в себя подготовку программного обеспечения и действия по переходу, такие как концепция и создание плана сопровождения; подготовка к решению проблем, выявленных в процессе разработки; и последующие меры по управлению конфигурацией продукта.
- Процесс анализа проблем и модификаций, который выполняется после того, как приложение становится ответственным за группу обслуживания. Программист обслуживания должен анализировать каждый запрос, подтверждать его (воспроизводя ситуацию) и проверять его действительность, исследовать его и предлагать решение, задокументировать запрос и предложение решения и, наконец, получить все необходимые разрешения для применения изменений.
- Процесс с учетом реализации самой модификации.
- Процесс принятия модификации путем подтверждения измененной работы с лицом, отправившим запрос, чтобы убедиться, что модификация предоставила решение.
- Процесс миграции ( например, миграция платформы ) является исключительным и не является частью ежедневных задач обслуживания. Если программное обеспечение необходимо перенести на другую платформу без каких-либо изменений в функциональности, будет использоваться этот процесс, и для выполнения этой задачи, вероятно, будет назначена группа проекта обслуживания.
- Наконец, последний процесс обслуживания, также событие, которое не происходит ежедневно, - это списание части программного обеспечения.
Существует ряд процессов, действий и практик, которые уникальны для специалистов по сопровождению, например:
- Переход: контролируемая и скоординированная последовательность действий, во время которой система постепенно передается от разработчика к обслуживающему персоналу.
- Соглашения об уровне обслуживания (SLA) и специализированные (зависящие от предметной области) контракты на техническое обслуживание, заключаемые сопровождающими
- Служба поддержки запросов на изменение и отчетов о проблемах: процесс обработки проблем, используемый специалистами по обслуживанию для определения приоритетов, документирования и маршрутизации получаемых ими запросов.
Категории обслуживания программного обеспечения [ править ]
EB Swanson первоначально выделил три категории обслуживания: корректирующее, адаптивное и совершенное. [7] Стандарт IEEE 1219 был заменен в июне 2010 года стандартом P14764 . [8] С тех пор они были обновлены, и ISO / IEC 14764 представляет:
- Корректирующее обслуживание : реактивная модификация программного продукта, выполняемая после доставки для исправления обнаруженных проблем. Корректирующее обслуживание можно автоматизировать с помощью автоматического исправления ошибок .
- Адаптивное сопровождение: модификация программного продукта, выполняемая после поставки, чтобы программный продукт оставался пригодным для использования в изменившейся или меняющейся среде.
- Безупречное сопровождение: модификация программного продукта после доставки для повышения производительности или ремонтопригодности .
- Профилактическое обслуживание : модификация программного продукта после доставки для обнаружения и исправления скрытых ошибок в программном продукте до того, как они станут действующими ошибками.
Существует также понятие обслуживания перед доставкой / выпуском, которое представляет собой все хорошее, что вы делаете для снижения общей стоимости владения программным обеспечением. Такие вещи, как соответствие стандартам кодирования, которые включают в себя цели ремонтопригодности программного обеспечения. Управление связью и связностью программного обеспечения. Достижение целей поддержки программного обеспечения (например, SAE JA1004, JA1005 и JA1006). Некоторые академические учреждения [ кто? ] проводят исследования для количественной оценки затрат на текущее обслуживание программного обеспечения из-за нехватки ресурсов, таких как проектная документация, обучение и ресурсы для понимания системы / программного обеспечения (умножьте затраты примерно на 1,5–2,0, если данные по проекту отсутствуют).
Факторы обслуживания [ править ]
Влияние ключевых корректирующих факторов на техническое обслуживание (отсортировано в порядке максимального положительного воздействия)
| Факторы обслуживания | Плюс Диапазон |
|---|---|
| Специалисты по обслуживанию | 35% |
| Высокий кадровый опыт | 34% |
| Табличные переменные и данные | 33% |
| Низкая сложность базового кода | 32% |
| Проблема 2000 года и специальные поисковые системы | 30% |
| Инструменты реструктуризации кода | 29% |
| Инструменты реинжиниринга | 27% |
| Языки программирования высокого уровня | 25% |
| Инструменты обратного инжиниринга | 23% |
| Инструменты анализа сложности | 20% |
| Инструменты отслеживания дефектов | 20% |
| Специалисты по «массовому обновлению» 2000 года | 20% |
| Инструменты автоматического управления изменениями | 18% |
| Неоплачиваемая сверхурочная работа | 18% |
| Измерения качества | 16% |
| Формальные проверки базового кода | 15% |
| Библиотеки регрессионных тестов | 15% |
| Отличное время отклика | 12% |
| Ежегодное обучение> 10 дней | 12% |
| Высокий управленческий опыт | 12% |
| ПОМОЩЬ автоматизация рабочего стола | 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% |
[9]
Задолженность по содержанию [ править ]
В документе для 27-й Международной конференции по управлению качеством программного обеспечения в 2019 году [10] Джон Эстдейл ввел термин «задолженность по обслуживанию» для потребностей в обслуживании, вызванных зависимостью реализации от внешних ИТ-факторов, таких как библиотеки, платформы и инструменты, которые стали устаревший. [11] Приложение продолжает работать, и ИТ-отдел забывает об этой теоретической ответственности, сосредотачиваясь на более неотложных требованиях и проблемах в других местах. Такой долг со временем накапливается, незаметно съедая стоимость программного актива. В конце концов происходит что-то, что делает изменение системы неизбежным.
Затем владелец может обнаружить, что система больше не может быть изменена - она буквально не обслуживается. Менее радикально то, что техническое обслуживание может занять слишком много времени или слишком дорого для решения бизнес-проблемы, и необходимо найти альтернативное решение. Программное обеспечение внезапно упало до 0 фунтов стерлингов.
Estdale определяет «долг обслуживания» [11] как разрыв между текущим состоянием реализации приложения и идеальным, с использованием только функциональных возможностей внешних компонентов, которые полностью поддерживаются и поддерживаются. Этот долг часто скрывается или не признается. Общая ремонтопригодность приложения зависит от постоянной доступности всех видов компонентов от других поставщиков, включая:
- Инструменты разработки: редактирование исходного кода, управление конфигурацией, компиляция и сборка
- Инструменты тестирования: выбор тестов, выполнение / проверка / отчетность
- Платформы для выполнения вышеперечисленного: оборудование, операционная система и другие услуги.
- Производственная среда и любые средства резервного / аварийного восстановления, включая среду поддержки времени выполнения исходного кода и более широкую экосистему планирования заданий, передачи файлов, реплицированного хранилища, резервного копирования и архивирования, единого входа и т. Д.
- Отдельно приобретаемые пакеты, например СУБД, графика, связь, промежуточное ПО
- Куплено в исходном коде, библиотеках объектного кода и других вызываемых сервисах
- Любые требования, возникающие из других приложений, совместно использующих производственную среду или взаимодействующих с рассматриваемым приложением.
и конечно
- Наличие соответствующих навыков внутри компании или на рынке.
Полное исчезновение компонента может привести к невозможности перестроения приложения или невозможности его обслуживания.
См. Также [ править ]
- Отмена приложения
- Журнал поддержки и развития программного обеспечения: исследования и практика
- Долгосрочная поддержка
- Разработка программного обеспечения на основе поиска
- Программная археология
- Сопровождающий программного обеспечения
- Разработка программного обеспечения
Ссылки [ править ]
[12]
- ^ «ISO / IEC 14764: 2006 Разработка программного обеспечения - Процессы жизненного цикла программного обеспечения - Обслуживание» . Iso.org. 2011-12-17 . Проверено 2 декабря 2013 .
- ^ Пигоски, Томас М., 1997: Практическое сопровождение программного обеспечения: передовой опыт управления инвестициями в программное обеспечение. Компьютерный паб Wiley. (Нью-Йорк)
- ^ Eick, S., Graves, Т., Карр А., Marron, J., и Моцкус, A. 2001. Имеет ли код Распад? Оценка свидетельств из данных управления изменениями. IEEE Transactions по разработке программного обеспечения. 27 (1) 1-12.
- ^ Линц Б., Суонсон Э., 1980: Управление обслуживанием программного обеспечения. Эддисон Уэсли, Ридинг, Массачусетс
- ^ Lehman MM, 1980: Программа, жизненные циклы и законы эволюции программного обеспечения. В материалах IEEE, 68, 9,1060-1076
- ^ Пенни Грабб, Армстронг А. Таканг, 2003: Сопровождение программного обеспечения: концепции и практика. Всемирная научная издательская компания
- ^ "Э. Берт Свансон, Размеры обслуживания. Труды 2-й международной конференции по разработке программного обеспечения, Сан-Франциско, 1976, стр. 492 - 497" . Portal.acm.org. DOI : 10.1145 / 359511.359522 . S2CID 14950091 . Проверено 2 декабря 2013 . Цитировать журнал требует
|journal=( помощь ) - ^ Статус 1219-1998 по стандартам IEEE
- ^ «Экономика сопровождения программного обеспечения в двадцать первом веке» (PDF) . Архивировано из оригинального (PDF) 19 марта 2015 года . Проверено 2 декабря 2013 .
- ^ Хан, О; Марчбанк, П; Георгиаду, Э; Линейный автомобиль, P; Росс, М; Скобы, G (2019). Proc управления качеством программного обеспечения XXVII: международный опыт и инициативы в области управления качеством ИТ . Саутгемптон: Университет Солент. ISBN 978-1-9996549-2-4.
- ^ a b Эстдейл, Джон. Промедление с техническим обслуживанием может оказаться фатальным . в [11]. С. 95–106.
- ^ Пигоски, Томас. «Глава 6: Обслуживание программного обеспечения» (PDF) . SWEBOK . IEEE . Проверено 5 ноября 2012 года .
Дальнейшее чтение [ править ]
- ISO / IEC 14764 IEEE Std 14764-2006 Разработка программного обеспечения - Процессы жизненного цикла программного обеспечения - Обслуживание . 2006. DOI : 10,1109 / IEEESTD.2006.235774 . ISBN 0-7381-4960-8.
- Пигоски, Томас М. (1996). Практическое сопровождение программного обеспечения . Нью-Йорк: Джон Вили и сыновья. ISBN 978-0-471-17001-3.
- Пигоски, Томас М. Описание эволюции и сопровождения программного обеспечения (версия 0.5) . Область знаний SWEBOK.
- Апрель, Алена; Абран, Ален (2008). Управление обслуживанием программного обеспечения . Нью-Йорк: Wiley-IEEE. ISBN 978-0-470-14707-8.
- Гопаласвами Рамеш; Рамеш Бхаттипролу (2006). Сопровождение программного обеспечения: эффективные методы для географически распределенных сред . Нью-Дели: Тата Макгроу-Хилл. ISBN 978-0-07-048345-3.
- Грабб, Пенни; Таканг, Армстронг (2003). Сопровождение программного обеспечения . Нью-Джерси: World Scientific Publishing. ISBN 978-981-238-425-6.
- Леман, ММ; Белады, Л.А. (1985). Эволюция программы: процессы изменения программного обеспечения . Лондон: ISBN Academic Press Inc. 0-12-442441-4.
- Пейдж-Джонс, Мейлир (1980). Практическое руководство по проектированию структурированных систем . Нью-Йорк: Yourdon Press. ISBN 0-917072-17-0.
Внешние ссылки [ править ]
- Журнал обслуживания программного обеспечения
| vтеИнформатика | ||
|---|---|---|
Примечание. Этот шаблон примерно соответствует Системе классификации вычислений ACM 2012 года . | ||
| Аппаратное обеспечение |
| |
| Организация компьютерных систем |
| |
| Сети |
| |
| Организация программного обеспечения |
| |
| Обозначения и инструменты программного обеспечения |
| |
| Разработка программного обеспечения |
| |
| Теория вычислений |
| |
| Алгоритмы |
| |
| Математика вычислений |
| |
| Информационные системы |
| |
| Безопасность |
| |
| Взаимодействие человека с компьютером |
| |
| Параллелизм |
| |
| Искусственный интеллект |
| |
| Машинное обучение |
| |
| Графика |
| |
| Прикладные вычисления |
| |
| ||
Категория
Контур
ВикиПроект
Commons| vтеПрограммная инженерия | |||||||
|---|---|---|---|---|---|---|---|
| Поля |
| ||||||
| Концепции |
| ||||||
| Ориентации |
| ||||||
| Модели |
| ||||||
| Инженеры- программисты |
| ||||||
| Связанные поля |
| ||||||
| |||||||
| vтеСтандарты ISO по номеру стандарта | |
|---|---|
Список стандартов ISO / romanizations ISO / стандартам МЭК | |
| 1–9999 |
|
| 10000–19999 |
|
| 20000–29999 |
|
| 30000+ |
|
| |
