Фаза сопровождения в жизненном цикле, обычно, начинается сразу после при-емки/передачи продукта и действует в течение периода гарантии или технической поддержки. Объективная потребность в сопровождении связана:
- • с обнаружением при эксплуатации ПП скрытых дефектов и необходимости устранение сбоев;
- • улучшением дизайна;
- • реализацией новых функциональных возможностей;
- • созданием интерфейсов взаимодействия с внешними системами;
- • адаптацией для обеспечения возможности работы ПП на другой программно-аппаратной платформе;
- • изменением бизнес-процессов в предметной области;
- • выводом программного обеспечения из эксплуатации.
Процесс сопровождения выполняется как перед вводом системы в эксплуатацию, так и после этого и состоит из планирования деятельности по сопровождению системы, организации перехода к ее полнофункциональному использованию, обучения пользователей и их ежедневной поддержки при работе с текущей версией продукта. Если новая система должна заменить старую систему, важно обеспечить плавный переход со старой системы на новую максимально естественно для пользователей.
Премиум-сопровождение программ 1С
Область знаний «Сопровождение ПО» состоит из следующих описаний разделов (рис. 20).
Рис. 1.20 — Область знаний «Сопровождение ПО»
Основы сопровождения
Этот раздел содержит описание содержания концепции и терминологию, формирующие основы понимания роли и содержания работ по сопровождению ПО.
Сопровождение программного обеспечения определяется стандартами как:
- • совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки ПО;
- • модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении;
- • процесс модификации программного продукта в части его кода и документации для решения возникающих проблем при эксплуатации или реализации новых потребностей пользователей, улучшения тех или иных характеристик продукта;
- • модификация программного продукта в процессе эксплуатации при условии сохранения целостности продукта.
Деятельность персонала сопровождения включает четыре ключевых аспекта: поддержку контроля программного обеспечения в течение всего цикла эксплуатации; поддержку модификаций ПО; совершенствование существующих функций; предотвращение снижения производительности ПО до критического уровня.
В зависимости от исходных условий состояния ПО в стандартах выделяется четыре категории сопровождения:
- • Корректирующее сопровождение: «реактивная» модификация программного продукта, выполняемая уже после передачи в эксплуатацию для устранения сбоев.
- • Адаптирующее сопровождение: модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной эффективностью (с точки зрения удовлетворения потребностей пользователей) в изменившемся или находящемся в процессе изменения окружении, в первую очередь подразумевается изменение бизнес-окруже-ния, порождающее новые требования к ПО.
- • Совершенствующее сопровождение: модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения.
- • Профилактическое сопровождение: модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям.
Ключевые вопросы сопровождения программного обеспечения
Сопровождение и сервисное обслуживание Вашей программы 1С.BAS от Rearden Group
Для обеспечения эффективного сопровождения ПО необходимо решать целый комплекс вопросов и проблем, связанных с соответствующими работами. Эти вопросы и проблемы сгруппированы в стандарте по следующим темам:
- • Технические вопросы.
- • Управленческие вопросы.
- • Вопросы оценка стоимости сопровождения.
- • Вопросы измерения.
К группе технических вопросов по сопровождению ПО относятся:
- • анализ и понимание персоналом программного кода ПО, которое он не разрабатывал, а также необходимость внести исправления или изменения в код;
- • организация работ по тестированию модификаций эксплуатируемого ПО, вплоть до предварительного планирования и разработки регламентов, в соответствии с которыми персоналом сопровождения будут проводиться стандартные процедуры;
- • анализ возможных последствий и влияний изменений, вносимых в существующее ПО, оценка рисков, связанных с внесением изменений.
Сущность управленческих вопросов состоит в контроле качества ПО в процессе модификации функционала и недопущении снижения производительности.
Оценка стоимости затрат на сопровождение зависит от типа ПО, квалификации персонала, платформы и др. Знание этих факторов позволяет не только их сохранить, но и уменьшить.
Вопросы измерения относятся к оценке характеристик ПО после его модификации. В качестве типичных метрик оценки работ по сопровождению, соответствующих распространенной классификации эксплуатационных характеристик программного обеспечения, рекомендуется использовать:
- • анализируемость: оценка ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов ПО, которые должны быть модифицированы;
- • изменяемость: оценка ресурсов, необходимых для проведения заданных модификаций;
- • стабильность: оценка режимов непредусмотренного поведения ПО, включая ситуации, обнаруженные в процессе тестирования;
• тестируемость: оценка трудозатрат персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.
Процесс сопровождения
Необходимо рассматривать процесс сопровождения как эволюционную модификацию ПО, поскольку сданное в эксплуатацию ПО не всегда является полностью завершенным, его надо изменять в течение срока эксплуатации. В результате ПО становится более сложным и плохо управляемым.
Рис. 1.21 — Варианты модернизации ПО
В этом случае возможны четыре варианта развития событий при модификации ПО (рис. 1.21):
- 1) пользователям приходится смириться с отсутствием некоторых функциональных возможностей программного обеспечения или их несоответствием новым реалиям и выполнять их либо вручную, либо при помощи подручных инструментов, например Word и Excel. Соответственно возрастает трудоемкость обработки, вероятность ошибок (человеческий фактор), требуется обучение и коррекция мотивации персонала, а главное — теряется драгоценное время;
- 2) в обход ограничений ПО (врожденных или приобретенных в ходе эволюции бизнеса) создаются дополнительные компоненты («заплатки»). Здесь к риску допуска новых ошибок добавляются издержки на исследование «обходных путей», их программирование и отладку;
- 3) если первые два варианта решения неприемлемы, то тогда разработчик начинает реализацию изменений на уровне исходных текстов, что требует ресурсов, а главное — времени на завершение полного цикла разработки, тестирование и разворачивание новой версии ПО;
- 4) наиболее пессимистичное развитие ситуации, когда критичные для заказчика требования нс только нс покрываются ПО и всеми его штатными средствами настройки, но и разработчик в силу различных причин не берется реализовать их путем доработок или переработок программного кода и предлагает заново осуществлять выбор новой платформы и разрабатывать новое решение. Это может привести просто к катастрофе бизнеса, сокращению доли рынка, реальных доходов от продаж, снижению конкурентных преимуществ.
Техники сопровождения
Для реализации изменений программисты тратят значительную часть времени на чтение и формирование понимания в большинстве случаев чужого программного кода. Средства работы с кодом являются ключевым инструментом для решения этой задачи. Четкая, однозначная и лаконичная документация обеспечивает адекватное понимание ПО.
Общепринятыми техниками, используемыми в процессе сопровождения ПО, являются: реинжиниринг, обратный инжиниринг и рефакторинг.
Реинжиниринг — это улучшение возможностей, функций в устаревшем ПО путем его реорганизации и реструктуризации, перепрограммирования или настройки на другую платформу или среду с обеспечением удобства его сопровождения.
Обратный инжиниринг состоит в анализе программного обеспечения с целью идентификации программных компонент и связей между ними, восстановлении спецификации по полученному коду ПО (особенно, когда в нее внесено много изменений) для наблюдения за ней на более высоком уровне. Конечными целями обратного инжиниринга могут быть: создание новой документации на существующее ПО; восстановление дизайна и т. д.
Рефакторинг — трансформация программного обеспечения, в процессе которого ПО реорганизуется (не переписываясь) с целью улучшения структуры, без изменения ее функционала. Рефакторинг ориентирован на улучшение структурных характеристик и качественных показателей объектно-ориентированных программ без изменения их поведения. Этот процесс реализуется путем изменения отдельных операций над текстами, интерфейсами, средой программирования и выполнения ПО, а также настройки или внесения изменений в инструментальные средства поддержки ПО.
Источник: ozlib.com
Сопровождение программного обеспечения
Сопровождение программного обеспечения представляет собой управление изменениями программного продукта, поддержку его текущего состояния и функциональную пригодность, а также адаптацию поставляемого программного обеспечения к новым условиям. Как правило, изменения, вносимые в процессе сопровождения, не касаются основных функций программного обеспечения, однако могут потребовать пересмотра проектных решений, принятых на любом этапе жизненного цикла.
Цель этапа сопровождения — поддержка пользователей программного обеспечения, улучшение, оптимизация и устранение дефектов ПО после передачи его в эксплуатацию.
Сопровождаемость программного обеспечения — совокупность характеристик программного продукта, позволяющих минимизировать усилия по внесению в него изменений для устранения ошибок и для модификации в соответствии с изменяющимися потребностями пользователей. Можно выделить три типа сопровождения:
- • корректирующее, называемое обычно исправлением ошибок, — выполняется при обнаружении ошибок, когда не требуется внесения изменений в спецификации требований. В этом случае проводится диагностика и исправление ошибок в программном обеспечении с целью поддержания системы в работоспособном состоянии;
- • адаптивное — осуществляется при необходимости изменения данных или среды исполнения, когда система улучшается или расширяется, добавляются новые функции, в связи с этим изменяется спецификация требований;
- • усовершенствующее (прогрессивное) — включает любые модификации с целью повышения эффективности работы или сопровождения системы.
Принято выделять несколько линий сопровождения:
- • 0-я линия (call-center, информационный центр, горячая линия) — обработка телефонных обращений от клиентов, передача обращений техническим специалистам (на 1-ю линию сопровождения);
- • 1 -я линия (инженер по сопровождению, инженер технической поддержки, support engineer) — консультация, настройка, устранение ошибок в работе программного обеспечения, наполнение базы знаний, составление руководства пользователей;
- • 2-я линия (инженер по сопровождению, инженер технической поддержки, support engineer) — функциональное сопровождение, проектная деятельность на этапе запуска программного обеспечения на оборудовании заказчика;
• 3-я линия (инженер по сопровождению, инженер технической поддержки, support engineer) — системное сопровождение, проектная деятельность на этапе запуска программного обеспечения на оборудовании заказчика.
Работу инженера по сопровождению ошибочно сравнивают с работой информационного центра. Однако по функционалу эти специалисты принципиально различаются — если call-center фактически аккумулирует обращения пользователей, то сопровождение является центральным звеном в цепочке разработки и доработки ПО, которое решает проблемы, возникающие в период эксплуатации ПО (системы, сервиса).
Инженер по сопровождению (инженер технической поддержки, support) — специалист, занимающийся поддержанием корректной работы процессов, сервисов, программного обеспечения на всех этапах разработки. Инженер по сопровождению должен обладать навыками планирования и быть организованным, способным работать в режиме многозадачности с большим количеством переключений. Задача инженера — устранить проблему в кратчайшие сроки, он должен хорошо разбираться в предметной области сопровождаемого программного обеспечения, сервиса и уметь составлять техническое задание смежным подразделениям. Это невозможно без знания языков программирования, баз данных, навыков администрирования программного обеспечения, аналитического мышления и внимательности.
Источник: studref.com
Обслуживание программного обеспечения
Обслуживание программного обеспечения в Разработка программного обеспечения — это модификация программного продукта после доставки, чтобы исправить ошибки, улучшить производительность или другие атрибуты.
Распространенное мнение, что обслуживание состоит в том, что оно просто включает исправление дефектов. Однако одно исследование показало, что более 80% усилий по техническому обслуживанию расходуется на некорректирующие действия. Это восприятие поддерживается пользователями, отправляющими отчеты о проблемах, которые на самом деле являются расширением функциональности системы. Более поздние исследования показывают, что доля исправлений ошибок приближается к 21%.
История
Обслуживание программного обеспечения и эволюция систем впервые была рассмотрена Меиром М. Леманом в 1969 году. В течение двадцати лет его исследования привели к формулировке законов Лемана ( Lehman 1997).
Основные результаты его исследования заключаются в том, что обслуживание — это действительно эволюционное развитие и что решениям по обслуживанию помогает понимание того, что происходит с системами (и программным обеспечением) с течением времени. Lehman продемонстрировал, что системы продолжают развиваться с течением времени. По мере их развития они становятся более сложными, если не предпринимаются какие-либо действия, такие как рефакторинг кода, для уменьшения сложности. В конце 1970-х годов известное и широко цитируемое исследование, проведенное Линцем и Суонсоном, выявило очень высокую долю затрат на жизненный цикл, которые затрачивались на техническое обслуживание.
Опрос показал, что около 75% усилий по обслуживанию приходилось на первые два типа, а на исправление ошибок ушло около 21%. Многие последующие исследования предполагают аналогичный масштаб проблемы. Исследования показывают, что вклад конечных пользователей имеет решающее значение во время сбора и анализа новых данных о требованиях. Это основная причина любых проблем во время разработки и обслуживания программного обеспечения. Сопровождение программного обеспечения важно, потому что оно потребляет значительную часть общих затрат жизненного цикла, а также невозможность быстро и надежно изменить программное обеспечение означает, что возможности для бизнеса теряются.
Важность обслуживания программного обеспечения
Ключевые вопросы обслуживания программного обеспечения являются как управленческими, так и техническими. Ключевые вопросы управления: согласование с приоритетами клиентов, укомплектование персоналом, какая организация выполняет обслуживание, оценка затрат. Ключевые технические вопросы: ограниченное понимание, анализ воздействия, тестирование, измерение ремонтопригодности.
Обслуживание программного обеспечения — это очень широкая деятельность, которая включает исправление ошибок, расширение возможностей, удаление устаревших возможностей и оптимизацию. Поскольку изменения неизбежны, необходимо разработать механизмы оценки, контроля и внесения изменений.
Таким образом, любая работа по изменению программного обеспечения после его запуска считается работами по техническому обслуживанию. Цель — сохранить ценность программного обеспечения с течением времени. Ценность может быть увеличена за счет расширения клиентской базы, выполнения дополнительных требований, упрощения использования, повышения эффективности и использования новейших технологий. Техническое обслуживание может длиться 20 лет, тогда как разработка может длиться 1-2 года.
Планирование обслуживания программного обеспечения
Неотъемлемой частью программного обеспечения является обслуживание, которое требует подготовки точного плана обслуживания. во время разработки программного обеспечения. Он должен указать, как пользователи будут запрашивать изменения или сообщать о проблемах. Бюджет должен включать оценку ресурсов и затрат.
Новое решение должно быть рассмотрено для разработки каждой новой функции системы и ее целей в области качества. Техническое обслуживание программного обеспечения, которое может длиться 5–6 лет (или даже десятилетий) после процесса разработки, требует наличия эффективного плана, который может охватывать объем обслуживания программного обеспечения, адаптацию процесса после доставки / развертывания, определение того, кто предоставит техническое обслуживание и оценку стоимости жизненного цикла. Выбор надлежащего соблюдения стандартов — сложная задача с самого начала разработки программного обеспечения, которая не имеет особого значения для заинтересованных сторон.
Процессы сопровождения программного обеспечения
В этом разделе описываются шесть процессов сопровождения программного обеспечения как:
- Процесс внедрения включает в себя подготовку программного обеспечения и действия по переходу, такие как концепция и создание плана сопровождения; подготовка к решению проблем, выявленных в процессе разработки; и последующие действия по управлению конфигурацией продукта.
- Процесс анализа проблем и модификаций, который выполняется после того, как приложение становится ответственным за группу обслуживания. Программист обслуживания должен анализировать каждый запрос, подтверждать его (воспроизводя ситуацию) и проверять его действительность, исследовать его и предлагать решение, задокументировать запрос и предложение решения и, наконец, получить все необходимые разрешения для применения изменений. 54>
- Процесс, рассматривающий реализацию самой модификации.
- Процесс принятия модификации путем подтверждения измененной работы с лицом, подавшим запрос, чтобы убедиться, что модификация предоставила решение.
- Процесс миграции (миграция платформы, например) является исключительным и не является частью ежедневных задач обслуживания. Если программное обеспечение необходимо перенести на другую платформу без каких-либо изменений в функциональности, будет использоваться этот процесс, и для выполнения этой задачи, вероятно, будет назначена группа проекта обслуживания.
- Наконец, последний процесс обслуживания, также событие что не происходит на ежедневной основе, это списание части программного обеспечения.
Существует ряд процессов, действий и практик, которые уникальны для специалистов по сопровождению, например:
- Переход: контролируемая и скоординированная последовательность действий, в ходе которых система постепенно передается от разработчика к обслуживающему персоналу;
- Соглашения об уровне обслуживания (SLA) и специализированные (зависящие от домена) контракты на техническое обслуживание, согласовываемые специалистами по обслуживанию;
- Запрос на изменение и Служба поддержки отчетов о проблемах: процесс обработки проблем, используемый специалистами по обслуживанию для определения приоритетов, документирования и маршрутизации получаемых ими запросов;
Категории обслуживания программного обеспечения
EB Свонсон первоначально выделил три категории обслуживания: корректирующее, адаптивное и совершенное. Стандарт IEEE 1219 был заменен в июне 2010 года стандартом P14764 . С тех пор они были обновлены, и 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% |
| Опыт высшего руководства ence | 12% |
| Автоматизация рабочего стола HELP | 12% |
| Нет модулей, подверженных ошибкам | 10% |
| Отчетность о дефектах в режиме онлайн | 10% |
| Измерения производительности | 8% |
| Превосходная простота использования | 7% |
| Измерения удовлетворенности пользователей | 5% |
| Высокая боевой дух команды | 5% |
Не только модули, подверженные ошибкам, доставляют неудобства, но и многие другие факторы также могут ухудшить производительность. Например, очень сложный код спагетти довольно сложно безопасно поддерживать. Очень распространенная ситуация, которая часто снижает производительность, — это отсутствие подходящих инструментов обслуживания, таких как программное обеспечение для отслеживания дефектов, программное обеспечение для управления изменениями и программное обеспечение библиотеки тестов. Ниже описаны некоторые факторы и диапазон их влияния на обслуживание программного обеспечения.
Влияние ключевых поправочных факторов на обслуживание (отсортировано в порядке максимального негативного воздействия)
| Модули, подверженные ошибкам | -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% |
Долг за обслуживание
В докладе на 27-й Международной конференции по управлению качеством программного обеспечения в 2019 году Джон Эстдейл ввел термин «обслуживание задолженность »для обслуживания потребностей, вызванных зависимостью реализации от внешних ИТ-факторов, таких как библиотеки, платформы и инструменты, которые устарели. Приложение продолжает работать, и ИТ-отдел забывает об этой теоретической ответственности, сосредотачиваясь на более неотложных требованиях и проблемах в другом месте. Такой долг со временем накапливается, незаметно съедая стоимость программного актива. В конце концов происходит что-то, что делает изменение системы неизбежным.
После этого владелец может обнаружить, что система больше не может быть изменена — ее буквально невозможно поддерживать. Менее драматично, техническое обслуживание может занять слишком много времени или слишком дорого для решения бизнес-проблемы, и необходимо найти альтернативное решение. Программное обеспечение внезапно упало до 0 фунтов стерлингов.
Estdale определяет «долг обслуживания» как разрыв между текущим состоянием реализации приложения и идеальным, с использованием только функциональных возможностей внешних компонентов, которые полностью поддерживаются и поддерживаются. Этот долг часто скрывается или не признается. Общая ремонтопригодность приложения зависит от постоянной доступности всех видов компонентов от других поставщиков, включая:
- Инструменты разработки: редактирование исходного кода, управление конфигурацией, компиляция и сборка
- Инструменты тестирования: выбор тестов, выполнение / проверка / отчетность
- Платформы для выполнения вышеуказанного: оборудование, операционная система и другие службы
- Производственная среда и любые резервные средства / средства аварийного восстановления, включая среду поддержки времени выполнения исходного кода, и более широкая экосистема планирования заданий, передачи файлов, реплицированного хранилища, резервного копирования и архивирования, единого входа и т. д.
- Отдельно приобретаемые пакеты, например, СУБД, графика, связь, промежуточное ПО
- Куплено в исходном коде, библиотеках объектного кода и других вызываемых службах
- Любые требования, возникающие из других приложений, совместно использующих производственную среду или взаимодействующих с рассматриваемым приложением
- Доступность соответствующих sk проблемы, внутри компании или на рынке.
Полное исчезновение компонента может сделать приложение невозможным для восстановления или неизбежно невозможным поддерживать его.
См. Также
- Вывод приложений из эксплуатации
- Журнал поддержки и развития программного обеспечения: исследования и практика
- Долгосрочная поддержка
- Разработка программного обеспечения на основе поиска
- Археология программного обеспечения
- Программное обеспечение сопровождающий
- Разработка программного обеспечения
Ссылки
Дополнительная литература
- 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.
- Lehman, M.M.; Белады, Л.А. (1985). Эволюция программы: процессы изменения программного обеспечения. Лондон: Academic Press Inc. ISBN 0-12-442441-4.
- Пейдж-Джонс, Мейлир (1980). Практическое руководство по проектированию структурированных систем. Нью-Йорк: Yourdon Press. ISBN 0-917072-17-0.
Внешние ссылки
Источник: alphapedia.ru