Выбор модели жизненного цикла ПО.
Выбор модели жизненного цикла ПО.
Как уже отмечалось выше, существует ряд моделей жизненного цикла ПО с отличающейся терминологией для различных стадий. С точки зрения программной документации, не имеет значения, какая модель выбрана, до тех пор, пока стадии и соответствующая им документация четко определены, спланированы и выполнимы для любого конкретного программного проекта. Руководители должны выбрать соответствующую модель ЖЦ и гарантировать, чтобы ее применяли в данной организации. При этом руководители должны убедиться, что выбранные стадии и соответствующие задачи помогут им в контроле за ходом разработки ПО.
Проведем краткий анализ жизненных циклов программного обеспечения, описанных нами выше.
В рамках ИСО/МЭК 12207 документирования решаются при вызове каким-либо процессом ЖЦ процесса документирования.
Процесс документирования – это процесс записи информации, получаемой в процессе жизненного цикла или деятельности. Процесс состоит из набора действий, таких как планирование, проектирование, производство, редактирование, распространение и сопровождение документов, необходимых всем заинтересованным лицам проекта: менеджерам, инженерам и пользователям системы или ПО.
Процесс документирования состоит из следующих действий: реализации, проектирование и разработка, производство и сопровождение.
Реализация. Это действие состоит из следующих задач.
1 Планирование, определяющее, какие документы должны быть выпущены во время жизненного цикла ПО, что должно быть разработано, задокументировано и реализовано. Для каждого установленного документа должно быть указано следующее:
а) название или имя;
б) цель;
в) назначение;
г) процедуры и ответственность по вводу, разработке, осмотру, модификации, утверждению, производству, хранению, распространению, сопровождению и конфигурированию;
д) расписание промежуточной и конечной версий.
Проектирование и разработка. Это действие состоит из следующих задач.
1. Каждый документ должен быть спроектирован в соответствии с применяемыми стандартами по формату, содержанию, нумерации страниц, размещению рисунков/таблиц, отметке о приоритете/секретности, упаковке и другим пунктам.
2. Источник и соответствие входных данных для документов должны быть гарантированы. Должны быть использованы автоматические средства документирования.
3. Подготовленные документы должны быть просмотрены и отредактированы с точки зрения формата, технического содержания и стиля представления в соответствии со стандартами по документации. Они должны быть утверждены ответственным за их выпуск.
Производство. Это действие состоит из следующих задач.
1. Документы должны быть произведены и упакованы. В соответствии с планом, ими должны быть обеспечены все заинтересованные стороны. Производство и распространение документов может быть выполнено в бумажном, электронном виде. Исходные материалы должны храниться в соответствии с условиями записи, секретности, сопровождения и резервных копий проекта.
2. Контроль должен быть представлен в соответствии с процессом управления конфигурированием.
Сопровождение. Это действие состоит из следующих задач.
1. Задачи, необходимые для выполнения при модификации существующего ПО, должны быть исполнены.
Стадия “Рабочая документация” ГОСТ 34.601 частично соответствует привлечению процесса документирования процессов разработки по ИСО/МЭК 12207. Название данной стадии не точно отражает ее содержание, так как она содержит этап 6.2 - “Разработка или адаптация программ”. Кроме того, процесс документирования выполняется на стадиях эскизного и технического проекта. По ГОСТ 19.102 этап разработки программной документации появляется только на стадии “Рабочий проект”. Такое позднее начало документирования процессов ЖЦ не в состоянии обеспечить ни требуемого качества документации, ни требуемого качества ПО.
Таким образом, терминология и концепция в области документирования ИСО/МЭК 12207 представляются более удачными. Можно рекомендовать при использование ГОСТ 34.601 для этапов 4.2, 5.2, 5.3, 6.1 учитывать в содержании работ задачи, определенные в ИСО/МЭК 12207 для процесса документирования.
CUS.1 Процесс Приобретения
Базисный процесс
Цель Процесса Приобретения состоит в том, чтобы получить продукт и/или услугу, которое удовлетворяет потребность, выраженную заказчиком (клиентом). Процесс начинается с определения потребности заказчика и требуемых результатов с принятием продукта и/или услуги, необходимого заказчиком. В результате успешной реализации процесса:
- будет разработан контракт, который ясно выражает ожидания, обязанности и обязательства, как заказчика, так и поставщика;
- будет произведен продукт и/или услуга, что удовлетворит установленную потребность заказчика;
- приобретение будет проверено таким образом, чтобы определенные ограничения как, например, стоимость, план и качество были выполнены.
CUS.1.1 Процесс Подготовки Приобретения
Компонентный процесс CUS.1 – Процесса Приобретения
Цель Процесса Подготовки Приобретения состоит в том, чтобы установить потребности и цели приобретения. В результате успешной реализации процесса:
- будет установлена потребность в приобретении, разработке или расширении системы, программного продукта или процесса разработки ПО;
- будут сформулированы системные требования;
- будет разработана стратегия приобретения;
- будут определены приемочные критерии.
ENG.1 Процесс Разработки
Базисный процесс
Цель процесса Разработки состоит в том, чтобы трансформировать согласованный набор требований в функциональный программный продукт или программную систему, которые удовлетворяют установленным потребностям заказчика. В результате успешной реализации процесса:
- будет разработан программный продукт или программная система;
- будут разработаны промежуточные рабочие продукты, что показывает, что конечное изделие основывается на согласованных требованиях;
- будет установлена непротиворечивость между требованиями программного обеспечения и проектами программного обеспечения;
- данные тестирования будут показывать, что конечный продукт встречает согласованные требования;
- конечный продукт будет установлен в целевую среду и принят заказчиками.
ПРИМЕЧАНИЕ: Согласованные требования можно обеспечивать операцией процесса Приобретения (CUS. 1) или Процесса Установления Требований (CUS. 3).
ENG.1.1 Процесс Разработки и Анализа Системных Требований
Компонентный процесс ENG.1 – Процесса Разработки
Цель Процесса Разработки и Анализа Системных Требований состоит в том, чтобы установить системные требования (функциональные и нефункциональные) и архитектуру, идентифицируя, какие системные требования должны быть распределены к каким элементам системы и в какой версии. В результате успешной реализации процесса:
- будут разработаны системные требования, что соответствует установленным потребностям заказчика;
- будет предложено решение, идентифицирующее основные элементы системы;
- согласованные требования будут распределены каждому из основных элементов системы;
- будет разработана стратегия версии, определяющая приоритет для выполнения системных требований;
- системные требования будут одобрены и модифицированы, как и требуется;
- требования, предложенное решение и их связи будут сообщены всем заинтересованным сторонам.
SUP.1 Процесс Документирования
Расширенный Процесс
Цель Процесса Разработки Документации состоит в том, чтобы разработать и поддержать документы, которые записывают информацию, произведенную процессом или действием. В результате успешной реализации процесса:
- будет разработана стратегия, идентифицирующая документы, которые будут произведены в течение жизненного цикла программного продукта;
- будут определены стандарты, к которые должны обращаться за разработка документов;
- все документы, которые будут произведены процессом или проектом будут идентифицированы;
- содержание и цель всех документов будет определена, рассмотрена и одобрена;
- все документы будут разрабатываться и издаваться в соответствии с определенными стандартами;
- все документы будут поддерживаться в соответствии с определенными критериями.
ПРИМЕЧАНИЕ - процесс поддерживает исполнение атрибута процесса 2.2 в тех примерах, где он введен.
MAN.1.1 Процесс Управления Проектом
Компонентный процесс MAN.1 – процесса Управления
Цель Процесса Управления Проектом состоит в том, чтобы идентифицировать, устанавливать, координировать и контролировать действия, задачи и ресурсы, необходимые для проекта создания продукта и/или встречи услуги согласованным требованиям. В результате успешной реализации процесса:
- будет определена область работ проекта;
- будет оценена выполнимость достижения целей проекта с доступными ресурсами и ограничениями;
- будут измерены и оценены задачи и ресурсы, необходимые для завершения работы;
- будут идентифицированы и проверяться интерфейсы между элементами проекта и другими проектами и организационными модулями,;
- будут разработаны и выполняться планы выполнения проекта;
- будет проверен и сообщаться прогресс проекта;
- действия, чтобы исправить отклонения от плана и предотвращать рекуррентное соотношение проблем, идентифицированных в проекте, будут приниматься, когда цели проекта не достигнуты.
ПРИМЕЧАНИЕ - Этот процесс поддерживает исполнение атрибута процесса 2.1 в тех примерах, где он введен.
ORG.2 Процесс Усовершенствования
Базисный Процесс
Процесс Усовершенствования - процесс для установления, оценки, измерения, управления и улучшения процесса жизненного цикла программного обеспечения. В результате успешной реализации этого процесса:
- набор организационных активов процесса будет разработан и сделан доступным;
- возможность процесса организации будет периодически оценена, чтобы определить степень, в какой реализация процесса является эффективной в достижении целей организации;
Измерение возможности
Измерение возможности эталонной модели определяет шкалу измерения для оценки возможности процесса любого процесса. Возможность процесса определена на шести пунктах порядковой шкалы, которая позволяет оценить возможность из нижней части шкалы, незавершенного уровня, к верхнему концу шкалы, оптимизирующему уровню. Шкала определяет повышение возможности выполняемого процесса от эффективности, которая не способна к достижению определенных результатов вплоть до эффективности, которая является способной к достижению бизнес - цели и поддержке непрерывного улучшения процесса. Следовательно, шкала определяет четкий маршрут улучшения для каждого индивидуального процесса.
Внутри модели возможности, мера возможности основана на наборе из девяти атрибутов процесса (АП) (см. таблицу 4.1). Атрибуты процесса используются, чтобы определить, достиг ли процесс данной возможности. Каждый атрибут измеряет специфический аспект возможности процесса. Атрибуты самостоятельно измеряются в шкале процентов и, следовательно, обеспечивают более подробное понимание специфических аспектов возможности процесса, требуемой, чтобы поддерживать усовершенствование процесса и определение возможности.
Для примера, приведем один из атрибутов третьего уровня возможности.
AП 3.1 Атрибут определение и преобразование процесса
До какой степени ведется выполнение процесса в виде преобразованного экземпляра стандартного определения процесса. Стандартный процесс отвечает определенным бизнес - целям организации. Преобразование выполняется для соответствия специфическим целям экземпляра процесса. В результате полного достижения этого атрибута:
- документация процесса, вместе с соответствующим руководством на подгонку стандартной документации процесса, будет определена, что способно обеспечить нормальную область выполнения процесса и функциональные и нефункциональные требования к рабочему продукту;
- выполнение процесса будет проводиться в соответствии с выбранной и/или приспособленной стандартной документацией процесса;
- исторические данные выполнения процесса будут собраны, во-первых, чтобы устанавливать и совершенствовать понимание поведения процесса, во-вторых, чтобы оценить потребности ресурса выполнения процесса;
- опыты использования документации процесса будут использоваться, чтобы совершенствовать стандартный процесс.
Таблица 4.1.
| Номер | Название |
| Уровень 1 | Выполняемый процесс |
| АП 1.1 | Атрибут выполнения процесса |
| Уровень 2 | Управляемый процесс |
| AП 2.1 | Атрибут управления выполнением |
| AП 2.2 | Атрибут управления рабочим продуктом |
| Уровень 3 | Установленный процесс |
| АП 3.1 | Атрибут определения и преобразования процесса |
| АП 3.2 | Атрибут ресурса процесса |
| Уровень 4 | Предсказуемый процесс |
| AП 4.1 | Атрибут измерения процесса |
| AП 4.2 | Атрибут контроля процесса |
| Уровень 5 | Оптимизирующий процесс |
| AП 5.1 | Атрибут изменения (верификации) процесса |
| AП 5.2 | Атрибут возможности дальнейшего улучшения |
Атрибут процесса представляет измеримую характеристику любого процесса, как определено выше.
Шкала рейтинга – шкала в процентах, от ноля до ста, которая представляет степень достижения атрибута.
Порядковая шкала рейтинга, определенная ниже, должна использоваться, чтобы откалибровать уровни достижения определенной возможности атрибутов процесса.
N Не достигнутый:
0 % - 15 % - есть маленькое или нет вообще подтверждения достижения определенного атрибута.
P Частично достигнутый:
16 % - 50 % - есть подтверждение надежного систематического метода к достижению определенного атрибута. Некоторые аспекты достижения могут быть непредсказуемы.
L В значительной степени достигнутый:
51 % - 85 % - есть подтверждение надежного систематического метода к значительному достижению определенного атрибута. Выполнение процесса может измениться в некоторых областях.
F Полностью достигнутый:
86 % - 100 % - есть подтверждение полного и систематического метода к полному достижению определенного атрибута. Никаких значительных недостатков не существуют в пределах определенной части организации.
Каждый атрибут процесса, оцененный в любой части организации, включая самый высокий уровень возможности, определенный в сфере оценки, должен быть согласован с рейтингом, использующего шкалу атрибута, определенную выше. Набор рейтингов атрибута для процесса формирует профиль для этого процесса. Выход оценки включает набор профилей для всех оцененных процессов.
Каждый рейтинг атрибута процесса должен иметь ссылку, которая записывает имя процесса и оцененный атрибут процесса.
Используемый идентификатор должен давать объективное подтверждение использованию, чтобы определить рейтинг, который должен извлекаться. Рейтинги могут представляться в любом формате, как, например, матрицы или как часть базы данных, при условии, что представление допустит идентификацию индивидуальных рейтингов согласно этой схемы ссылки.
Уровень возможности, достигнутый процессом, должен быть получен из рейтинга атрибута для этого процесса, согласно модели уровня возможности процесса, определенной в таблице 4.2. Цель этого требования состоит в том, чтобы гарантировать единообразие значений, когда уровень возможности процесса ссылается для процесса.
Ниже приведены таблицы, содержащие итоговые списки процессов, которые включены в эталонная модель (таблица 4.3) и соответствие процессов эталонной модели и процессов, определенные в проекте стандарта ИСО/МЭК 12207 (таблица 4.4).
Таблица 4.2
| Шкала | Атрибуты процесса | Оценка |
| Уровень 1 | Выполнение процесса | В основном или полностью |
| Уровень 2 | Выполнение процесса Управление выполнением Управление рабочим продуктом | Полностью В основном или полностью В основном или полностью |
| Уровень 3 | Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса | Полностью Полностью Полностью В основном или полностью В основном или полностью |
| Уровень 4 | Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса Измерение процесса Контроль процесса | Полностью Полностью Полностью Полностью Полностью В основном или полностью В основном или полностью |
| Уровень 5 | Выполнение процесса Управление выполнением Управление рабочим продуктом Определение и преобразование процесса Ресурс процесса Измерение процесса Контроль процесса Изменение процесса Возможность дальнейшего улучшения | Полностью Полностью Полностью Полностью Полностью Полностью Полностью В основном или полностью В основном или полностью |
Таблица 4.3.
| Категория процесса | Процесс | |||
| Номер | Название | Номер | Название | |
| Начальные процессы жизненного цикла | ||||
| CUS | Категория процесса поставщик – заказчик | |||
| CUS.1 | Приобретение (базисный) | |||
| CUS.1.1 | Подготовка приобретения (компонентный) | |||
| CUS.1.2 | Выбор поставщика (компонентный) | |||
| CUS.1.3 | Проверка поставщика (компонентный) | |||
| CUS.1.4 | Одобрение заказчика (компонентный) | |||
| CUS.2 | Поддержка (базисный) | |||
| CUS.3 | Установление требований (новый) | |||
| CUS.4 | Функционирование (расширенный) | |||
| CUS.4.1 | Функциональное использование (расширенный компонентный) | |||
| CUS.4.2 | Поддержка пользователя (расширенный компонентный) | |||
| ENG | Категория процесса инжиниринга | |||
| ENG.1 | Разработка (базисный) | |||
| ENG.1.1 | Анализ и разработка системный требований (компонентный) | |||
| ENG.1.2 | Анализ требований ПО (компонентный) | |||
| ENG.1.3 | Разработка ПО (компонентный) | |||
| ENG.1.4 | Конструкция ПО (компонентный) | |||
| ENG.1.5 | Интеграция ПО (компонентный) | |||
| ENG.1.6 | Тестирование ПО (компонентный) | |||
| ENG.1.7 | Тестирование и интеграция системы (компонентный) | |||
| ENG.2 | Эксплуатация системы и ПО (базисный) | |||
| Поддерживающие процессы жизненного цикла | ||||
| SUP | Категория процесса поддержки | |||
| SUP.1 | Документирование (расширенный) | |||
| SUP.2 | Управление конфигурацией (базисный) | |||
| SUP.3 | Гарантия качества (базисный) | |||
| SUP.4 | Верификация (базисный) | |||
| SUP.5 | Проверка правильности (базисный) | |||
| SUP.6 | Совместный обзор (базисный) | |||
| SUP.7 | Проверка (базисный) | |||
| SUP.8 | Решение проблем (базисный) | |||
| SUP.9 | Измерение (новый) | |||
| SUP.10 | Повторного использования (новый) | |||
| Организационные процессы жизненного цикла | ||||
| MAN | Категория процесса управления | |||
| MAN.1 | Управление (базисный) | |||
| MAN.1.1 | Управление проектом (компонентный) | |||
| MAN.2 | Управление качеством (новый) | |||
| MAN.3 | Управление риском (новый) | |||
| ORG | Категория процесс организации | |||
| ORG.1 | Организационное выравнивание (новый) | |||
| ORG.2 | Процесс усовершенствования (базисный) | |||
| ORG.2.1 | Создание процесса (компонентный) | |||
| ORG.2.2 | Оценка процесса (компонентный) | |||
| ORG.2.3 | Усовершенствование процесса (компонентный) | |||
| ORG.3 | Управление человеческими ресурсами (расширенный) | |||
| ORG.4 | Инфраструктура (базисный) | |||
| Таблица 4.4. | |||||
| Действия и процессы 12207 | Процессы 15504 | Тип | |||
| 5. | Начальные процессы жизненного цикла | ||||
| 5.1 | Процесс приобретение | CUS.1 | Процесс приобретения | базисный | |
| 5.1.1 | Инициализация | CUS.1.1 | Процесс подготовки приобретения | Компонента | |
| 5.1.2 | Подготовка Заявки-для-Предложения [-заявка на подряд] | CUS.1.2 | Процесс выбора поставщика | Компонента | |
| 5.1.3 | Подготовка контракта и корректировка | CUS.1.2 | Процесс выбора поставщика | Компонента | |
| 5.1.4 | Проверка поставщика | CUS.1.3 | Процесс проверки поставщика | компонента | |
| 5.1.5 | Принятие и завершение | CUS.1.4 | Процесс одобрения заказчика | компонента | |
| 5.2 | Процесс поставки | CUS.2 | Процесс поставки | базисный | |
| 5.2.1 | Инициализация | CUS.2 | Процесс поставки | базисный | |
| 5.2.2 | Подготовка ответа | CUS.2 | Процесс поставки | базисный | |
| 5.2.3 | Контракт | CUS.2 | Процесс поставки | базисный | |
| 5.2.4 | Планирование | CUS.2 | Процесс поставки | базисный | |
| 5.2.5 | Выполнение и управление | CUS.2 | Процесс поставки | базисный | |
| 5.2.6 | Обзор и оценка | CUS.2 | Процесс поставки | базисный | |
| 5.2.7 | Поставка и завершение | CUS.2 | Процесс поставки | базисный | |
| CUS.3 | Процесс установления требований | новый | |||
| 5.3 | Процесс разработки | ENG.1 | Процесс разработки | базисный | |
| 5.3.1 | Реализация процесса | ENG.1 | Процесс разработки | базисный | |
| 5.3.2 | Анализ системных требований | ENG.1.1 | Процесс разработки и анализа системных требований | компонента | |
| 5.3.3 | Разработка архитектуры системы | ENG.1.1 | Процесс разработки и анализа системных требований | компонента | |
| 5.3.4 | Анализ требований ПО | ENG.1.2 | Процесс анализа программных требований | компонента | |
| 5.3.5 | Разработка архитектуры ПО | ENG.1.3 | Процесс разработки ПО | компонента | |
| 5.3.6 | Рабочий проект ПО | ENG.1.3 | Процесс разработки ПО | компонента | |
| 5.3.7 | Кодирование и тестирование ПО | ENG.1.4 | Процесс конструкции ПО | компонента | |
| 5.3.8 | Интеграция ПО | ENG.1.5 | Процесс интеграции ПО | компонента | |
| 5.3.9 | Тестирование квалификации ПО | ENG.1.6 | Процесс тестирования ПО | компонента | |
| 5.3.10 | Интеграция системы | ENG.1.7 | Процесс тестирования и интеграции системы | компонента | |
| 5.3.11 | Тестирование квалификации системы | ENG.1.7 | Процесс тестирования и интеграции системы | компонента | |
| 5.3.12 | Инсталляция ПО | CUS.2 | Процесс поставки | базисный | |
| 5.3.13 | Поддержка программ | CUS.2 | Процесс поставки | базисный | |
| 5.4 | Процесс функционирования | CUS.4 | Процесс функционального использования | базисный | |
| 5.4.1 | Реализация процесса | CUS.4.1 | Процесс функционального использования | расширенная компонента | |
| 5.4.2 | Функциональное тестирование | CUS.4.1 | Процесс функционального использования | расширенная компонента | |
| 5.4.3 | Функционирование системы | CUS.4.1 | Процесс функционального использования | расширенная компонента | |
| 5.4.4 | Поддержка пользователя | CUS.4.2 | Процесс поддержки пользователя | расширенная компонента | |
| 5.5 | Процесс эксплуатации | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 5.5.1 | Реализация процесса | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 5.5.2 | Анализ проблем и модификаций | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 5.5.3 | Реализация модификации | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 5.5.4 | Принятие в эксплуатацию | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 5.5.5 | Миграция | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 5.5.6 | Утилизация ПО | ENG.2 | Процесс эксплуатации ПО и системы | базисный | |
| 6. | Вспомогательные процессы жизненного цикла | ||||
| 6.1 | Процесс документирования | SUP.1 | Процесс документирования | расширенный | |
| 6.1.1 | Реализация процесса | SUP.1 | Процесс документирования | расширенный | |
| 6.1.2 | Разработка и развитие | SUP.1 | Процесс документирования | расширенный | |
| 6.1.3 | Продукция | SUP.1 | Процесс документирования | расширенный | |
| 6.1.4 | Эксплуатация | SUP.1 | Процесс документирования | расширенный | |
| 6.2 | Процесс управления конфигурацией | SUP.2 | Процесс управления конфигурацией | Базисный | |
| 6.2.1 | Реализация процесса | SUP.2 | Процесс управления конфигурацией | базисный | |
| 6.2.2 | Идентификация конфигурации | SUP.2 | Процесс управления конфигурацией | базисный | |
| 6.2.3 | Контроль конфигурации | SUP.2 | Процесс управления конфигурацией | базисный | |
| 6.2.4 | Учет статуса конфигурации | SUP.2 | Процесс управления конфигурацией | базисный | |
| 6.2.5 | Оценка конфигурации | SUP.2 | Процесс управления конфигурацией | базисный | |
| 6.2.6 | Управление выпуском и поставкой | SUP.2 | Процесс управления конфигурацией | базисный | |
| 6.3 | Процесс гарантии качества | SUP.3 | Процесс гарантии качества | базисный | |
| 6.3.1 | Реализация процесса | SUP.3 | Процесс гарантии качества | базисный | |
| 6.3.2 | Гарантия продукта | SUP.3 | Процесс гарантии качества | базисный | |
| 6.3.3 | Гарантия процесса | SUP.3 | Процесс гарантии качества | базисный | |
| 6.3.4 | Системы гарантии качества | SUP.3 | Процесс гарантии качества | базисный | |
| 6.4 | Процесс верификации | SUP.4 | Процесс верификации | базисный | |
| 6.4.1 | Реализация процесса | SUP.4 | Процесс верификации | базисный | |
| 6.4.2 | Верификация | SUP.4 | Процесс верификации | базисный | |
| 6.5 | Процесс проверки достоверности | SUP.5 | Процесс проверки достоверности | базисный | |
| 6.5.1 | Реализация процесса | SUP.5 | Процесс проверки достоверности | базисный | |
| 6.5.2 | Проверка достоверности | SUP.5 | Процесс проверки достоверности | базисный | |
| 6.6 | Процесс совместного обзора | SUP.6 | Процесс совместного обзора | базисный | |
| 6.6.1 | Реализация процесса | SUP.6 | Процесс совместного обзора | базисный | |
| 6.6.2 | Обзоры управления проектом | SUP.6 | Процесс совместного обзора | базисный | |
| 6.6.3 | Технические обзоры | SUP.6 | Процесс совместного обзора | базисный | |
| 6.7 | Процесс проверки | SUP.7 | Процесс проверки | базисный | |
| 6.7.1 | Реализация процесса | SUP.7 | Процесс проверки | базисный | |
| 6.7.2 | Аудит | SUP.7 | Процесс проверки | базисный | |
| 6.8 | Процесс решения проблем | SUP.8 | Процесс решения проблем | базисный | |
| 6.8.1 | Реализация процесса | SUP.8 | Процесс решения проблем | базисный | |
| 6.8.2 | Решение проблем | SUP.8 | Процесс решения проблем | базисный | |
| SUP.9 | Процесс измерения | новый | |||
| SUP.10 | Процесс повторного использования | новый | |||
| 7. | Организационные процессы жизненного цикла | ||||
| 7.1 | Процесс управления | MAN.1 | Процесс управления | базисный | |
| 7.1.1 | Инициализация и определение области | MAN.1.1 | Процесс управления проектом | компонента | |
| 7.1.2 | Планирование | MAN.1.1 | Процесс управления проектом | компонента | |
| 7.1.3 | Выполнение и контроль | MAN.1.1 | Процесс управления проектом | компонента | |
| 7.1.4 | Обзор и оценка | MAN.1.1 | Процесс управления проектом | компонента | |
| 7.1.5 | Закрытие | MAN.1.1 | Процесс управления проектом | компонента | |
| MAN.2 | Процесс управления качеством | новый | |||
| MAN.3 | Процесс управления риском | новый | |||
| ORG.1 | Процесс организационного выравнивания | новый | |||
| 7.2 | Процесс инфраструктуры | ORG.4 | Процесс инфраструктуры | базисный | |
| 7.2.1 | Реализация процесса | ORG.4 | Процесс инфраструктуры | базисный | |
| 7.2.2 | Создание инфраструктуры | ORG.4 | Процесс инфраструктуры | базисный | |
| 7.2.3 | Эксплуатация инфраструктуры | ORG.4 | Процесс инфраструктуры | базисный | |
| 7.3 | Процесс усовершенствования | ORG.2 | Процесс усовершенствования | базисный | |
| 7.3.1 | Создание процесса | ORG.2.1 | Процесс создания процесса | компонента | |
| 7.3.2 | Оценка процесса | ORG.2.2 | Процесс оценки процесса | компонента | |
| 7.3.3 | Усовершенствование процесса | ORG.2.3 | Процесс усовершенстования | компонента | |
| 7.4 | Подготовка процесса | ORG.3 | Процесс управления человескими ресурсами | расширенный | |
| 7.4.1 | Реализация процесса | ORG.3 | Процесс управления человескими ресурсами | расширенный | |
| 7.4.2 | Подготовка существенной разработки | ORG.3 | Процесс управления человескими ресурсами | расширенный | |
| 7.4.3 | Подготовка реализации плана | ORG.3 | Процесс управления человескими ресурсами | расширенный | |
4.3 Выполнение оценки
Этот подраздел определяет набор минимальных требований для выполнения оценки. Они увеличат вероятность того, что результаты оценки процессов будут являются целевыми, беспристрастными, непротиворечивыми, повторимыми и представительными, и определят обстоятельства, при которых результаты оценки являются сравнимыми.
Требования формируют часть структуры оценки процесса, который:
поощряет самооценку;
принимает во внимание контекст, в котором оцененные процессы функционируют;
производит наборы рейтингов процесса (профили процесса);
через атрибуты процесса, применимые ко всем процессам, направляют возможность процессов, чтобы достигнуть их целей;
является соответствующим всем предметным областям и размерам организации.
Чтобы увеличить непротиворечивость оценок для оцениваемых процессов, необходимо обеспечить требования для проведения оценок. Требования помогают гарантировать, что выход оценки непротиворечив, обеспечивает подтверждение, чтобы доказать обоснованность оценки и проверять согласие с требованиями.
Вход должен быть определен до оценки и одобрен заказчиком оценки. Вход оценки, как минимум, должен определять следующее.
1. Личность заказчика оценки и его отношение к оцениваемой организации.
2. Цель оценки.
3. Сферу оценки, включая:
а) процессы, которые будут исследованы внутри организации;
б) самый верхний уровень возможности, который должен исследоваться;
в) часть организации, которая разворачивает эти процессы;
г) контекст процесса, который, как минимум, включает: размер организации; демографию организации; предметную область продукта или услуг организации; размер, уязвимость и сложность изделий или услуг; качественные характеристики изделий (см., например, ИСО/МЭК 9126-91 Характеристики качества ПО).
4. Ограничения целостности оценки, которые могут включать:
а) доступность ключевых ресурсов;
б) максимальное количество времени, которое должно использоваться для оценки;
в) специфические процессы, которые должны быть исключены из оценки;
г) минимальный, максимальный или специфический типовой размер или покрытие, которое желательно для оценки;
д) собственность на выполнение оценки и любые ограничения на их использование;
е) средства управления на информацию, следующей из соглашения конфиденциальности.
5. Подлинность модели, используемой в пределах оценки, которая должна быть совместима с хорошей модель инжиниринга ПО, и встречающая требования, рассмотренные в подразделе 4.2.
6. Личности экспертов-консультантов, включая компетентного эксперта-консультанта, ответственного за оценку.
7. Личности экспертов-консультантов и персонала поддержки со специфическими обязанностями для оценки.
8. Любая дополнительная информация, которая будет собрана в течение оценки, чтобы поддерживать улучшение процесса или определение возможности процесса.
Любые изменения во входах оценки должны быть согласованными с заказчиком и зарегистрироваться в записи оценки. Заказчик оценки должен проверять, что эксперт-консультант, который должен брать ответственность за оценку и наблюдать за ней (компетентный эксперт-консультант), имеет необходимую компетентность и умения. Эксперт-консультант должен подтвердить требования заказчика, чтобы приступить к оценке.
Компетентный эксперт-консультант должен гарантировать, что оценка проводится в соответствии с определенными требованиями и принимает во внимание релевантные руководства в других частях ИСО/МЭК 15504.
Эксперт-консультант должен гарантировать, что все друг