2.4 Процессы жизненного цикла разработки ПО

ИСО/МЭК 12207-95 определяет модель жизненного цикла процессов разработки программного обеспечения. Данная модель жизненного цикла ПО определяет, на верхнем уровне, фундаментальные цели, которые являются существенными для разработки высокоэффективного и надежного программного обеспечения. Цели верхнего уровня описывают то, что должно быть достигнуто, а не как их достигнуть.
Жизненный цикл, определенный данным стандартом, применим в любой software-организации, желающей утвердить, а в последствии и улучшить возможности по поставке, разработке, эксплуатации, развитии и поддержке программного обеспечения. Модель не предполагает использование специфических организационных структур, философии управления, технологии или методологии разработки ПО.
Архитектура данной модели организует процессы для помощи персоналу организации в их понимании и их использования для непрерывного усовершенствования процессов разработки программного обеспечения. Процессы, определенные в стандарте, образуют всеобъемлющий набор процессов. Организация, в зависимости от своих целей и для их реализации, может выбрать соответствующий поднабор. Поэтому стандарт разработан так, чтобы быть приспособленным как для отдельной организации, так и для конкретного проекта или приложения. Кроме того, он может использоваться в случаях, когда программное обеспечение является самостоятельной сущностью, встраивается или является составной частью общей системы.
ИСО/МЭК 12207 не поддерживает (не устанавливает) какую-либо конкретную модель жизненного цикла программного обеспечения, управление программным обеспечением, метод разработки или локальную промышленную технологию. Еще раз повторим, что он также не предписывает, каким образом исполнять что-либо. Эти моменты очень сильно зависят от условий конкретного проекта и технологического уровня организации и остаются в ее компетенции.
Данный стандарт сильно связан со следующими стандартами, которые будут рассмотрены нами ниже. 
ИСО/МЭК 15504, Информационная технология - Оценка процесса разработки программного обеспечения;
ИСО 9001: 1994, Системы качества - Модель для обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании.
Все действия, которые могут осуществляться в процессе жизненного цикла ПО, рассматриваемый стандарт разбивает на три группы процессов жизненного цикла, согласно типу действия, которым они направляются. Каждый процесс жизненного цикла подразделяется на ряд действий. Каждое действие, в свою очередь, подразделяется на ряд задач. Под задачей понимается действие, преобразующее входы в выходы. Перечень задач, приведенный ниже, не является исчерпывающим и приведен в качестве примера. Процессы, действия, и задачи могут выполняться последовательно, параллельно, повторно и комбинировано.

Основные процессы. Раздел 5 ИСО/МЭК 12207 определяет, что основными процессами являются:
1. Процесс приобретения. Определяет действия заказчика, организации, приобретающего систему или программный продукт.
2. Процесс поставки. Определяет действия поставщика, организации, предоставляющей программный продукт заказчику.
3. Процесс разработки. Определяет действия разработчика, организации, определяющей и разрабатывающей программный продукт.
4. Процесс эксплуатации. Определяет действия оператора, организации, предоставляющей для пользователей услуги по эксплуатации компьютерной системы в ее рабочей среде.
5. Процесс сопровождения. Определяет действия сопровождающего, организации, предоставляющей услуги по сопровождению программного обеспечения; т.е., управлению изменениями в программном обеспечении для поддержки его в актуальном и работоспособном состоянии. Этот процесс включает перемещение и отставку программного обеспечения.
Сопроводительные процессы. Раздел 6 данного стандарта представляет собой соединение восьми процессов. Сопроводительный процесс поддерживает работу других процессов как единое целое с четко определенной целью и способствует успеху и качеству проекта. Сопроводительный процесс используется, как правило, другими процессами. Сопроводительные процессы:
1. Процесс документирования. Определяет действия для записи информации, происходящие во время жизненного цикла.
2. Процесс управления конфигурацией. Определяет действия по управлению конфигурацией.
3. Процесс гарантии качества. Определяет действия, обеспечивающие гарантию того, что программные продукты соответствуют определенным для них требованиям и придерживаются установленных планов.
4. Процесс верификации. Определяет действия (для заказчика, поставщиков или независимой стороны) по верификации программных продуктов различной глубины, в зависимости от конкретного проекта ПО.
5. Процесс аттестации. Определяет действия (для заказчика, поставщиков или независимой стороны) для аттестации программных продуктов проекта.
6. Процесс общего обзора. Определяет действия оценки статуса и качества продуктов. Этот процесс может быть использован любыми из двух сторон, где одна сторона (проверяющая) проверяет другую сторону (проверяемую).
7. Процесс аудита. Определяет действия для установления согласия с требованиями, планами и контрактами. Этот процесс может быть использован двумя сторонами, где одна сторона (аудитор) проводит аудит программных продуктов или действий другой стороны (подвергающейся аудиту).
8. Процесс разрешения проблем. Определяет действия для анализа и устранения проблем (включая несогласие), природа или источник которых обнаружены в течение разработки, эксплуатации, сопровождения или других процессов.

Организационные процессы. Раздел 7 ИСО/МЭК 12207 состоит из четырех процессов. Они используются организацией на верхнем уровне для установления, выполнения и усовершенствовании нижележащей структуры, построенной на связи процессов жизненного цикла и личностей организации. Обычно они используются вне сферы конкретных проектов и контрактов; однако уроки, извлеченные из этих проектов и контрактов, способствуют усовершенствованию организации. Организационные процессы:
1. Процесс управления. Определяет основные действия по управлению, включая управление проектом, в течение процессов жизненного цикла.
2. Процесс инфраструктуры. Определяет основные действия на установления нижележащей структуры процесса.
3. Процесс усовершенствования. Определяет основные действия, выполняемые организацией (заказчиком, поставщиком, разработчиком, эксплуатирующей, сопровождающей организацией или менеджером другого процесса) для установления, оценки, проверки и совершенствования процессов жизненного цикла.
4. Процесс обучения. Определяет действия по обеспечению соответственно подготовленного персонала.
Кратко рассмотрим перечисленные выше процессы.
5.1Приобретение
Процесс приобретения содержит действия и задачи заказчика. Процесс начинается с определения потребностей в приобретении системы или программных продуктов, продолжается подготовкой и выпуском заявок на предложение, выбором поставщика и управлением процесса приобретения посредством принятия программного продукта.
Заказчик управляет процессом приобретения на уровне проекта в соответствии с процессом управления (7.1), который подтверждается примерами в этом процессе, закладывает инфраструктуру в процессе согласно процессу инфраструктуры (7.2); подгоняет процесс для проекта согласно процессу подгонки и управляет процессом на организационном уровне согласно процессу усовершенствования (7.3).
Перечень действий: Этот процесс содержит следующие действия:
инициализация;
подготовка заявки_для_ предложения;
подготовка контракта и корректировка;
поиск поставщиков;
принятие и заключение.

5.1.1 Инициализация.
Это действие состоит из следующих основных задач:
Заказчик начинает процесс приобретения, выявляя идею или необходимость приобретения, разработки или усиления системы или программного продукта.
Заказчик должен определить и анализировать системные требования. Системные требования должны включать безопасность, надежность и другие критичные требования, касающиеся проектирования, тестирования и согласованными со стандартами и процедурами. Если заказчик приглашает поставщика для исполнения анализа требований системы, он должен одобрить проанализированные требования. Заказчик может выполнить установление требований к программному продукту самостоятельно или может пригласить поставщика для выполнения этой задачи. Процесс разработки (5.3) может быть использован для выполнения задач, указанных выше.
Заказчик будет обсуждать варианты приобретения, анализируя риск при каждом варианте. Варианты включают:
приобретение готового к использованию программного продукта, удовлетворяющего требованиям;
разработка программного продукта самостоятельно
разработка программного продукта через контракт
комбинация перечисленных выше вариантов.
усовершенствование существующего программного продукта.
Заказчик должен подготовить план приобретения, определяющий соответственно требования к планируемому использованию системы, тип контракта, который будет использован, обязанности привлеченных организаций, концепцию поддержки, которая будет использована, и риски, принимаемые во внимание, также методы управления рисками. План должен быть зарегистрирован и выполнен.
Аквизитор должен определить и зарегистрировать стратегию приемки и условия (критерии).

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

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

5.3 Процесс разработки
Процесс разработки содержит действия и задачи разработчика. Процесс содержит действия для анализа требований, проектирования, программирования, интеграции, тестирования и инсталляции и приемки, относящейся к программному обеспечению. Он может содержать системные действия, если это оговаривается в контракте.
Разработчик руководит процессом разработки на уровне проекта согласно процессу управления (7.1), который сопровождается примерами в этом процессе; представляет инфраструктуру процесса согласно процессу инфраструктуры (7.2); доводит процесс для проекта, следуя процессу доводки, и руководит процессом на организационном уровне, следуя процессу усовершенствования (7.3).
Перечень действий: Этот процесс состоит из следующих видов деятельности.
1. Инструментарий процесс. Это действие состоит из следующих задач:
Если не оговорено в контракте, разработчик должен определить или выбрать модель жизненного цикла программного обеспечения в соответствии с назначением, значимостью и сложностью проекта. Действия и задачи этого процесса должны быть выбраны и отображены в модели жизненного цикла. Эти действия и задачи могут перекрываться или взаимодействовать и могут быть исполнены итеративно или рекурсивно.
Разработчик должен выполнять следующее:
документировать результаты в соответствии с процессом документирования (раздел 6.1);
разместить результаты (выходы) в процессе конфигурации (6.2) и выполнить контроль изменений в соответствии с этим;
документировать и разрешить проблемы и несоответствия, найденные в программном продукте и задачах в соответствии с процессом разрешения проблем (6.8);
другие сопроводительные процессы (6), как определено в контракте.
Разработчик должен выбрать, довести и использовать внутренние стандарты, методологии, процедуры и языки программирования (если это не оговорено в контракте), которые должны быть зарегистрированы, соответствуют и установлены организацией для исполнения действий процесса разработки и процесса поддержки.
Разработчик должен разработать планы управления действиями в процессе разработки. Планы должны включать особые стандарты, методы, средства, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая надежность и безопасность. Эти планы должны быть зарегистрированы и исполнены.
Официально непоставляемые элементы могут быть использованы в разработке или сопровождении программного обеспечения. Однако должна быть гарантия того, что эксплуатация и поддержка поставляемого программного обеспечения после его поставки заказчику не зависит от таких элементов, другими словами, эти элементы становятся официально поставляемыми.
2. Анализ системных требований. Это действие состоит из следующих задач, которые разработчик должен исполнить или поддерживать, как требуется по контракту.
Особое предполагаемое использование разрабатываемых систем должно быть проанализировано для определения системных требований. Спецификация системных требований должна описывать: функции и возможности системы; надежность, защиту, разработку, интерфейс требования по эксплуатации и поддержке; ограничения проектирования и квалификационные требования. Спецификации системных требований должны быть зарегистрированы.
Системные требования должны быть оценены с позиций следующих критериев: прослеживаемость потребностей заказчика, согласованность с потребностями заказчика, тестируемость, выполнимость системного проектирования, осуществимость эксплуатации и поддержки.
3. Системное проектирование. Это действие состоит из следующих задач, которые разработчик должен выполнить или поддерживать, как требуется контрактом.
Должна быть представлена архитектура верхнего уровня системы. Архитектура должна определять элементы аппаратного, программного обеспечения и ручные операции. Должна быть гарантия того, что все системные требования полностью распределены среди элементов. Эти элементы должны быть впоследствии определены как элементы аппаратной конфигурации (ЭАК), элементы конфигурации программного обеспечения (ЭКПО) и соответственно ручные операции. Архитектура системы и системные требования, распределенные между элементами аппаратной, конфигурации, конфигурации ПО и ручными операциями, должны быть зарегистрированы.
Архитектура системы и требования для элементов конфигурации и ручных операций должны быть оценены в соответствии со следующими критериями:
различимость системных требований;
согласованность с системными требованиями;
соответствие стандартам и используемым методам проектирования;
осуществимость наполнения элементов конфигурации ПО распределенными для них требованиями;
выполнимость эксплуатации и поддержки.
4. Анализ требований к программному обеспечению. Для каждого ЭКПО это действие состоит из следующих задач, которые разработчик должен исполнить.
Разработчик должен представить и зарегистрировать требования к программному обеспечению, включая спецификации характеристик качества, описанных ниже:
спецификации функций и возможности, включая исполнение, физические характеристики, условия окружающей среды, при которых выполняется программное обеспечение;
внешний интерфейс ЭКПО;
квалификационные требования;
спецификации безопасности, включая относящиеся к методами эксплуатации и поддержки, влиянию окружающей среды и повреждению персоналом;
спецификации защиты, включая касающиеся особой информации и материалов;
человеческий фактор и спецификации человеко-машинного взаимодействия, включая относящиеся к ручным операциям, человеко-машинным взаимодействиям, ограничениям на персонал и области, требующие концентрации человеческого внимания, чувствительные с точки зрения ошибок человека и его опыта;
требования определения данных и требования к базам данных;
требования по инсталляции и приемке поставляемого программного обеспечения в эксплуатацию и сопровождение;
документация пользователя;
требования по эксплуатации пользователя и исполнению;
требования по пользовательскому сопровождению.
Руководство по определению характеристик качества может быть найдено в ИСО/МЭК 9126.
Разработчик должен оценить требования к программному обеспечению, руководствуясь приведенными ниже критериями:
прослеживаемость системных требований и системного проекта;
внешняя согласованность с системными требованиями;
внутренняя согласованность;
тестовое покрытие требований;
тестируемость;
выполнимость проектирования программного обеспечения;
осуществимость эксплуатации и сопровождения.
Разработчик должен руководить общим обзором в соответствии с 6.6. После успешного завершения обзора должна быть представлена основа для требований к ЭКПО.
5. Проектирование программного обеспечения. Для каждого ЭКПО это действие состоит из следующих задач, которые разработчик должен быть выполнить.
Разработчик должен преобразовать требования для ЭКПО в архитектуру, описывающую структуру его верхнего (высшего) уровня и определяющую главные компоненты. Должна быть гарантия того, что требования к ЭКПО полностью распределены между его компонентами и далее уточнены для облегчения детального проектирования.
Разработчик должен разработать и зарегистрировать:
проект высшего уровня для внешнего взаимодействия с ЭКПО и между компонентами программного обеспечения;
проект высшего уровня для баз данных;
предварительные версии руководства для пользователя;
предварительные тестовые требования и план интеграции программного обеспечения.
Разработчик должен оценить архитектуру ЭКПО и проекты интерфейса и баз данных, руководствуясь приведенными ниже критериями:
прослеживаемость требований к ЭКПО;
внешняя согласованность с требованиями к ЭКПО;
внутренняя согласованность между компонентами;
соответствие методов проектирования и стандартов, которые были использованы;
выполнимость детализированного проектирования
осуществимость эксплуатации и сопровождения.
Разработчик должен руководить общим обзором в соответствии с 6.6.
6. Детальное проектирование программного обеспечения. Для каждого ЭКПО это действие состоит из следующих задач, которые разработчик должен выполнить.
Разработчик должен разработать детальный проект для каждого компонента программного обеспечения ЭКПО. Компоненты программного обеспечения должны быть уточнены на нижних уровнях, содержащих модули программного обеспечения, которые могут кодироваться, компилироваться и тестироваться. Должна быть гарантия того, что требования к программному обеспечению полностью локализованы в модулях программного обеспечения. Детализированный проект должен быть зарегистрирован.
Разработчик должен разработать и задокументировать детальный проект для внешнего интерфейса ЭКПО между компонентами программного обеспечения и между модулями программного обеспечения. Детальный проект интерфейса должен позволять писать код программы без необходимости в дополнительной информации.
Разработчик должен разработать и зарегистрировать детальный проект базы данных.
Разработчик должен обновить руководство пользователя насколько это необходимо.
Разработчик должен определить и задокументировать тестовые требования и расписание тестирования блоков программного обеспечения. Тестовые требования должны включать испытания программного обеспечения на пределе требований.
Разработчик должен обновить тестовые требования и расписание интеграции программного обеспечения.
Разработчик должен оценить детальный проект программного обеспечения и тестовые требования с точки зрения критериев, приведенных ниже:
прослеживаемость требований ЭКПО;
внешняя согласованность с архитектурой проекта;
внутренняя согласованность между компонентами и модулями;
соответствие методов проектирования и используемых стандартов;
выполнимость тестирования;
выполнимость эксплуатации и сопровождения.
Разработчик должен руководить объединением согласно 6.6.
7. Программирование и отладка. Для каждого ЭКПО это действие состоит из следующих задач, которые должен выполнить разработчик.
Разработчик должен разработать и задокументировать следующее:
а) каждый модуль программного обеспечения и базы данных;
б) процедуры тестирования и данные для тестирования каждого модуля и базы данных.
Разработчик должен тестировать каждый модуль ПО и базы данных, убеждаясь в том, что они удовлетворяют требованиям. Результаты тестирования должны быть задокументированы.
Разработчик должен обновить руководство пользователя, тестовые требования и расписание интеграции ПО, оценить код ПО и результаты теста в соответствии с критериями, приведенными ниже:
прослеживаемость требований ЭКПО и проекта;
внешняя согласованность с требованиями ЭКПО и архитектурой проекта;
внутренняя согласованность между требованиями модулей;
тестирование модулей;
соответствие методов кодирования и используемых стандартов;
выполнимость интеграции ПО и тестирования;
выполнимость эксплуатации и сопровождения.
8. Интеграция программного обеспечения. Для каждого ЭКПО это действие состоит из следующих задач, которые должен выполнить разработчик.
Разработчик должен разработать план интеграции для объединения модулей ПО и компонентов в ЭКПО. План должен включать требования, процедуры, данные, ответственность и расписание.
Разработчик должен объединить модули ПО и компоненты. Должна быть гарантия того, что каждый компонент удовлетворяет требованиям SCI и что SCI полностью интегрирован как результат этой деятельности. Интеграция и результаты теста должны быть задокументированы.
Разработчик должен обновить руководство пользователя, если это требуется.
Разработчик должен разработать и задокументировать для каждого квалификационного требования ЭКПО полный набор тестов, ситуаций (вход, выход, критерии тестирования) и процедуры тестирования для управления квалификационным тестированием ПО.
Разработчик должен оценить план интеграции, проект, код, тесты, результаты тестирования и руководства пользователя с точки зрения критериев, приведенных ниже:
отслеживаемость системных требований;
внешняя согласованность с системными требованиями;
внутренняя согласованность;
тестирование ЭКПО требований;
соответствие используемых стандартов и методов тестирования;
соответствие с ожидаемыми результатами;
выполнимость квалификационного тестирования ПО;
выполнимость эксплуатации и сопровождения.
Разработчик должен руководить общим обзором в соответствии с 6.6.
9. Квалификационное тестирование программного обеспечения. Для каждого ЭКПО это действие состоит из следующих задач, которые должен выполнить разработчик:
Разработчик должен руководить квалификационным тестированием в соответствии с квалификационными требованиями, особыми для ЭКПО. Должно быть гарантировано, что реализация каждого требования к ПО полностью протестирована. Результаты квалификационного тестирования должны быть зарегистрированы.
Разработчик должен оценить проект, код, тесты, результаты тестирования и руководство пользователя в соответствии с приведенными ниже критериями:
тестирование требований к ЭКПО;
согласованность с ожидаемыми результатами;
выполнимость системной интеграции и тестирования;
выполнимость эксплуатации и сопровождения.
Разработчик должен поддерживать аудит в соответствии с 6.7. Результаты аудита должны быть задокументированы. Если разрабатываются или интегрируются ПО и аппаратное обеспечение, аудит может быть отложен до квалификационного тестирования системы.
После успешного завершения аудита, если предписано, разработчик должен:
а) обновить и подготовить к поставке ПО для системной интеграции, квалификационного тестирования системы, инсталляции или поддержки приема ПО, как полагается;
б) представить основную линию проектирования и кодирования ЭКПО;
10. Системная интеграция. Это действие состоит из следующих задач, которые должен выполнить разработчик.
ЭКПО должен быть интегрирован с ЭАК, руководством по эксплуатации и другими системами в единую систему. Составляющие должны быть протестированы на соответствие требованиям. Интеграция и результаты тестирования должны быть задокументированы.
Для каждого квалификационного требования к системе должны быть разработаны и задокументированы полный набор тестов, ситуаций (входных, выходных, критериев тестирования), процедур тестирования. Разработчик должен гарантировать, что интегрированная система готова для квалификационного тестирования.
Интегрированная система должна быть оценена в соответствии с приведенными ниже критериями:
зона тестирования требований к системе;
приемлемость используемых методов и стандартов тестирования;
согласованность с ожидаемыми результатами;
выполнимость квалификационного тестирования системы;
выполнимость эксплуатации и сопровождения.
11. Квалификационное тестирование системы. Это действие состоит из следующих задач, выполняемых разработчиком.
Квалификационное тестирование системы должно руководствоваться в соответствии с квалификационными требованиями, определенными для системы. Должно быть гарантировано, что выполнение каждого требования к системе протестировано полностью и система готова к поставке. Результаты квалификационного тестирования должны быть задокументированы.
Система должна быть оценена в соответствии с приведенными ниже критериями:
зона тестирования требований к системе;
подтверждение ожидаемыми результатами;
выполнимость эксплуатации и сопровождения.
Разработчик должен поддерживать аудит в соответствии с 6.7. Результаты аудита должны быть задокументированы. Этот пункт не применяется к таким ЭКПО, для которых аудит был выполнен ранее.
После успешного завершения аудита, если предписано, разработчик должен:
обновить и подготовить к поставке ЭКПО для инсталляции ПО и его приемки;
обосновать основные направления для проектирования и кодирования ЭКПО.
12. Инсталляция ПО. Это действие состоит из следующих задач, выполняемых разработчиком.
Разработчик должен разработать план инсталляции ПО в намеченную среду. Ресурсы и информация, необходимые для установки ПО, должны быть определены и доступны. Разработчик должен помогать поставщику при установке. После того, как ПО установлен в существующую систему, Разработчик должен поддерживать некоторые параллельно выполняемые действия. План установки должен быть задокументирован.
Разработчик должен установить ПО в соответствии с планом установки. Должно быть гарантировано, что ПО и базы данных инициализируются, функционируют и прекращают работу, как указано в контракте. Процесс установки и результаты должны быть задокументированы.
12. Поддержка приемки ПО. Это действие состоит из следующих задач, выполняемых разработчиком.
Разработчик должен поддерживать процесс приемки поставщиком и тестирование ПО. Приемка и тестирование должны основываться на общем обзоре, аудите, квалификационном тестировании, квалификационном тестировании системы (если оно выполнялось). Результаты приемки и тестирования должны быть задокументированы.

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

5.5 Процесс сопровождения
Процесс поддержки состоит из действий и задач лица, выполняющего сопровождение. Этот процесс начинается, когда необходима модификация из-за допущенных ошибок, неучтенных проблем, необходимости усовершенствования или адаптации кода ПО и соответствующей документации. Его цель - модифицировать существующее ПО, сохранив его целостность. Этот процесс включает распространение и замену ПО. Процесс завершается заменой ПО.
Действия, обеспечиваемые этим разделом, определены как процесс сопровождения, однако процесс может использовать другие процессы этого стандарта. Если используется процесс разработки (5.3), термин разработчик интерпретируется как обеспечивающий сопровождение. Обеспечивающий сопровождение руководит процессом сопровождении на уровне проекта, следуя процессу управления (7.3).
Перечень действий. Процесс состоит из следующих действий: процесс реализации, анализ проблем и модификации, реализация модификации, приемка, распространение, замена ПО.
В силу ограниченности объема данного учебного пособия, остальные процессы жизненного цикла ПО, установленные в ИСО/МЭК 12207, рассматривать не будем.