15.3. Задачи и процессы переноса программ и данных на иные

Это продолжение увлекательной статьи про сопровождение программных средств.

...

деятельности, работ и задач;

• состав отчетных материалов по этапам, затратам и графикам проведения работ;

• периодичность и способы выдачи отчетных материалов;

• состав отчетных материалов по проблемам и устраненным дефектам;

— время начала и длительность сопровождения. Рекомендуется сопроводителям формализовать конкретный план

сопровождения ПС из представленного общего состава процессов ЖЦ, который уточнить и адаптировать с учетом объема и особенностей проекта, содержащий разделы:

• описание сопровождаемой системы, в которую входит ПС;

• концепция сопровождения комплекса программ; описание уровня сопровождения системы и ПС; установление длительности процессов сопровождения; адаптация стандартизированных процессов сопровождения;

• организационные работы по сопровождению, роли и обязанности специалистов;

• ресурсы: состав специалистов; инструментальные средства; технические средства; документы и планы;

• процессы — как должна быть выполнена конкретная деятельность;

• определение уровня обучения, необходимого для сопроводителей и для пользователей;

— протоколы и отчеты по сопровождению; контрольные данные, собранные при работах по сопровождению.

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

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

• разработать схему классификации и присвоения приоритетов для предложенных модификаций и описаний дефектов;

• разработать процедуры проведения целевых анализов изменений;

• определить процедуры представления предложенных модификаций и описаний дефектов оператором;

• определить организацию обратной связи с пользователями при анализе изменений;

• определить, как пользователей будут обслуживать в период реализации сопровождения;

• определить, как будут введены предлагаемые модификации в базу данных учета состояний изменений и используемых ресурсов.

Анализ дефектов и модификаций в стандарте ISO 14764 рекомендуется реализовать в следующем порядке:

• анализируются предложения о модификации и отчеты о дефектах;

• дублируется или проверяется реальность каждого дефекта;

• разрабатываются варианты реализации изменения;

• документально оформляются: предложения о модификации и отчеты о дефектах, результаты их рассмотрения и варианты реализации изменений;

• проводится согласование выбранного варианта реализации изменения с заказчиком.

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

Для обеспечения реализации представленного предложения на изменение сопроводитель должен определить:

• наличие соответствующего персонала, способного реализовать предлагаемое изменение;

• наличие достаточного финансирования для реализации предлагаемого изменения в программе;

• наличие соответствующих ресурсов ЭВМ и степень влияния модификации на реализуемую или уже реализованные версии программного продукта;

• влияет ли отсутствие предполагаемых изменений на требования к системным интерфейсам, ожидаемый срок службы системы, приоритеты;

• влияние изменений на безопасность и защиту системы при эксплуатации;

• единовременные и долгосрочные затраты на корректировку;

• преимущества, получаемые после проведения модификации;

• влияние реализации изменений на графики проведения работ по версии программного продукта;

• необходимые процессы верификации, тестирования и оценки характеристик системы и программного продукта после внесения корректировки.

Для того чтобы подтвердить актуальность представленных отчетов о дефектах, сопроводитель должен продублировать и верифицировать возникшие проблемы — дефекты, выполнив следующие этапы решения данной задачи: разработать стратегию верификации и квалификационного тестирования для проверки устранения конкретной проблемы — дефекта; провести тестирование для проверки наличия проблемы — дефекта; документально оформить результаты квалификационного тестирования. Если конкретная проблема не может быть повторена сопроводителем, он должен проверить правила, политики и документы обеспечения ЖЦ ПС на предприятии. На основе проведенного анализа сопроводитель должен разработать варианты реализации изменения:

• присвоить соответствующий приоритет проблеме (дефекту) или предложению о модификации;

• установить наличие возможностей и средств для решения проблемы;

• оценить масштаб и трудоемкость данной модификации;

• разработать варианты реализации конкретного изменения;

• определить влияние данных вариантов на функциональную пригодность и технические средства системы;

• выполнить анализы риска для каждого варианта модификации.

Сопроводитель должен реализовать процесс управления конфигурацией для управления изменениями существующей системы или определить организационный интерфейс с данным процессом (см. лекцию 16). Результатами данной работы являются: план и процедуры сопровождения; процедуры решения проблем и устранения дефектов; планы организации обратной связи с пользователями; план передачи модификаций заказчику и пользователям. До внесения изменений в систему и программный продукт в соответствии с договором с заказчиком сопроводитель должен согласовать выбранный вариант корректировки.

Контроль за рассматриваемыми работами следует проводить посредством процесса совместного анализа. В конце работ должен быть проведен анализ риска. На основании выходных результатов анализа может быть пересмотрена предварительная оценка требуемых ресурсов и с привлечением пользователей или заказчика принято решение о целесообразности перехода к работе по внесению изменений в базовую версию программного продукта. Результатами этой работы являются: анализ влияния изменений; рекомендуемый вариант и согласованные изменения; обновленные и исправленные документы.

При внесении изменений в ПС сопроводитель разрабатывает и тестирует конкретные изменения программного продукта. Исходными данными для проведения работы при внесении изменений должны быть: базовая версия программного продукта; согласованные с заказчиком предложения о модификации; согласованные документы на реализацию корректировки; отчет о влиянии корректировки и выходные результаты работы по анализу изменений. Сопроводитель должен выполнить анализ использования процессов разработки комплекса программ при внесении изменений. После согласования корректировки сопроводителю следует провести анализ и определить, какие документы, программные модули и их версии требуют изменения. Результаты такого дополнительного анализа должны быть оформлены в комплекте документов процесса разработки базовой версии программного продукта:

— определены компоненты в существующей системе, подлежащие изменению;

• определены компоненты конкретного интерфейса, затрагиваемые данным изменением;

• определены документы, подлежащие обновлению;

• обновлен комплект документов базовой версии программного продукта;

• установлены и документально оформлены критерии проведения квалификационного тестирования и испытаний, оценки их результатов в измененных и неизмененных объектах (программных модулях, компонентах и элементах конфигурации) системы;

• обеспечены полнота и правильность реализации новых и измененных требований, обеспечено, чтобы исходные, неизмененные требования и целостность системы сохранились.

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

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

— отслеживание реализованных предложений о модификации и от четов о дефектах относительно требований предыдущей базовой версии проекта и программных кодов;

• проверку тестируемости текста (кодов) программы;

• проверку соблюдения стандартов на ЖЦ ПС и системы;

• проверку того, что изменены только нужные компоненты программного средства;

• проверку правильности сборки новых компонентов программного продукта;

• контроль обновления документов версии программного продукта;

• проверку полноты проведения тестирования и отчетов о тестировании.

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

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

Сопроводитель должен документально оформить и представить заказчику:

• отчеты о проблемах (дефектах) и предложения о модификациях; результаты их анализа и варианты реализации изменений;

• результаты приемочных испытаний, верификации, аттестации и измерений характеристик качества новой версии программного продукта;

• отчеты об обеспечении характеристик качества программного продукта и результаты их тестирования;

• результаты аудиторских проверок версии программного продукта;

• замечания заказчика и результаты взаимодействия с ним по устранению дефектов версии программного продукта;

• комплект актуальных проектных документов и документов результатов сопровождения;

• оценки корректности реализованной политики, графика и Программы квалификационного тестирования версии программного продукта;

• соотношение оценок необходимых и использованных ресурсов;

• официальные рекомендации с указаниями о целесообразных последующих модификациях и создании новых версий ПС.

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

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

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

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

Специалисты, выполняющие снятие программного продукта с сопровождения и эксплуатации, должны разработать план, предупредить пользо-

вателей об этом, провести соответствующее обучение персонала, уведомить всех заинтересованных субъектов о завершении сопровождения и архивировать соответствующие данные. В содержание плана необходимо включить:

• анализ требований к снятию с сопровождения и эксплуатации;

• оценку влияние снятия с сопровождения программного продукта на систему;

• установить программный продукт, заменяющий снимаемый (при его наличии);

• график и Программу снятия программного продукта с сопровождения и эксплуатации;

• определить и документировать все процедуры по снятию с сопровождения и эксплуатации;

• сроки прекращения полной или частичной поддержки сопровождения;

• требования по архивации версии и модификаций программного продукта и соответствующих документов;

• сроки перехода, при необходимости, к новой версии программного продукта;

• требования по доступу к архивным копиям данных проекта программного продукта.

Для плавного перехода к новой базовой версии программного продукта должна быть обеспечена параллельная эксплуатация прежнего и нового программных продуктов. В течение некоторого периода времени следует провести необходимое обучение пользователей новой версии в соответствии с условиями договора. После выполнения запланированного снятия с эксплуатации должно быть послано соответствующее уведомление всем заинтересованным сторонам. Все связанное с прежней версией ПС: документы разработки, журналы регистрации и программы — должно быть помещено в архивы. Данные, использованные или связанные со снятым с эксплуатации программным продуктом, следует сохранять доступными для аудиторской проверки. Целесообразно также сохранять старые версии ПС и некоторые данные, полученные при решении предыдущих задач в качестве тестов; создавать копии старых программных средств и данных, полученных при решении предыдущих задач; хранить соответствующие носители в безопасном месте.

15.3. Задачи и процессы переноса программ и данных на иные платформы

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

• процессы переноса программ и данных из одной аппаратной, операционной и пользовательской среды в иную по архитектуре и характеристикам среду с сохранением их целостности или небольшими изменениями функций системы;

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

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

• обеспечение сохранения инвестиций, вложенных в реализованные и апробированные программные продукты и базы данных, в процессе развития, модификации и появления новых требований к ним, а также при совершенствовании архитектур и возрастании ресурсов и функций аппаратных и операционных платформ;

• снижение трудоемкости, стоимости и длительности непосредственной разработки сложных распределенных программных средств и баз данных;

• обеспечение высокого качества, надежности и безопасности функционирования программных средств и баз данных в системах;

• обеспечение возможности эффективного по экономическим показателям и качеству переноса апробированных программных продуктов, разработанных должным образом, с минимальными изменениями на различные операционные системы и аппаратные платформы;

• экономная реализация совместной работы и расширения функций ПС (интероперабельность) во взаимодействии с другими программами и данными при решении единой целевой задачи на различных локальных и распределенных платформах;

• обеспечение взаимодействия с пользователями в унифицированном стиле, облегчающем им переход к использованию новых или с расширенными функциями системам и программным продуктам (мобильность пользователей);

• снижения зависимости заказчиков конкретных систем от определенных поставщиков аппаратных и операционных платформ, а также от разработчиков некоторых программных продуктов.

Для достижения перечисленных целей в обеспечении мобильности ПС требуются различные ресурсы при их реализации. Потребность в конкретных ресурсах и рентабельность их использования зависят от ряда параметров, которые образуют широкий спектр ситуаций для анализа и применения свойства мобильности программ и данных. Такими ресурсами являются:

• трудовые затраты специалистов и время на создание, приобретение и эксплуатацию инструментальных средств, автоматизирующих разработку и сопровождение мобильных ПС и БД;

• трудовые затраты специалистов и время на создание дополнительных интерфейсных компонентов в программах и данных, обеспечивающих их эффективную мобильность на определенные типы платформ, например, в соответствии с концепцией и стандартами открытых систем;

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

Задачи повторного использования и переноса программ и данных охватывают:

• встраивание готового программного средства и информации базы данных в создаваемую новую систему при условии, что их поставщики гарантируют функционирование на выбранной платформе;

• перенос программ и данных с платформ, в среде которых они были ранее реализованы, на выбранную для системы новую платформу;

• обеспечение доступа к информационным ресурсам других распределенных систем и сетей.

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

• системного анализа рентабельности переноса на иную или ту же платформу и оценки технико-экономических показателей этого процесса;

• реализации самого процесса переноса и интеграции с операционной и внешней средой на новой аппаратной платформе или в существующей среде;

• квалификационного тестирования, испытаний и комплексной проверки функционирования программного продукта в новом окружении или на новой платформе;

• сертификации перенесенного на новую платформу продукта и функционирующего в иной операционной и внешней среде;

— корректировки или дополнения эксплуатационной и технологи ческой документации.

Два последних вида работ могут выполняться в процессе создания мобильных ПС и БД и отсутствовать при непосредственной реализации переноса. Однако и в этом случае следует избегать излишнего оптимизма

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

Интеграционные тенденции развития современных ПС и БД связаны с сочетанием в них задач, относящихся к разным классам. Это определяет необходимость применения разных инструментальных средств для реализации программ, относящихся к разным классам, а также необходимость обеспечения функционирования создаваемых разными методами программ в единой целевой системе. Анализ мобильности программ и данных в системах касается различных классов задач, однако далее, для определенности, конкретные методы и средства обеспечения мобильности рассматриваются преимущественно применительно к задачам обработки данных в распределенных системах. При этом объектами анализа переносимости являются:

• программные модули и функциональные компоненты ПС;

• готовые (покупные) программные продукты и пакеты прикладных программ;

• крупные программные комплексы определенного функционального назначения;

• системы управления базами данных;

• файлы и информационные массивы баз данных;

• электронные документы на программы и данные.

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

выполняемых на каждой стадии жизненного цикла ПС, и определенные условия переходов между этапами ЖЦ позволяют выделить следующие уровни переноса и повторного использования ПС:

• модели предметной области и спецификаций требований, возможно, реализуемые разными способами на этапе проектирования ПС;

• проектные спецификации требований на этапе разработки ПС;

• исходные тексты программ на языках программирования, применявшихся при разработке повторно используемых программных компонентов;

• объектные коды программ, когда обеспечена структурная, аппаратная совместимость между исходной и целевой (реализующей) платформами;

• структуры файлов и информация баз данных;

• тесты проверки функционирования компонентов, тесты проверки соответствия повторно используемых программ стандартизированным интерфейсам, комплексных тестов.

Процессы переноса программ и данных на иные платформы, выбор методов обеспечения мобильности ПС и характеристики используемых ресурсов для их реализации, прежде всего, зависят от параметров компонентов, предполагаемых для переноса. Ресурсы требуются в той или иной степени на двух фазах процессов переноса программ и данных:

• при создании потенциально переносимых ПС и БД, когда свойства эффективной мобильности предусматриваются и реализуются при их разработке и определяются возможные платформы и области повторного использования таких программ и данных;

• при непосредственной реализации с соответствующими затратами процессов переноса ПС и БД, в различной степени подготовленных для переноса на иные платформы или для повторного использования на той же платформе.

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

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

В зависимости от степени программной совместимости между исходной и новой, целевой платформами можно рассматривать

продолжение следует...

Продолжение:

Часть 1 15 СОПРОВОЖДЕНИЕ И МОНИТОРИНГ ПРОГРАММНЫХ СРЕДСТВ
Часть 2 15.3. Задачи и процессы переноса программ и данных на иные
Часть 3 15.4. Ресурсы для обеспечения сопровождения и мониторинга программных средств -
Часть 4 - 15 СОПРОВОЖДЕНИЕ И МОНИТОРИНГ ПРОГРАММНЫХ СРЕДСТВ

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.