Архитектура эталонной модели искусственно включает два измерения:
измерение процесса, которое характеризует результаты процесса, являющиеся существенными измеримыми целями процесса;
измерение возможности процесса, которое характеризует набор атрибутов процесса, применимых к любому процессу и представляющие собой измеримые характеристики, которые необходимы для управления процессом и улучшающие возможность его выполнения.Эталонная модель группирует процессы, при измерение процесса, в три группы процессов жизненного цикла, которые содержат пять категорий процесса, согласно типу деятельности, к которым он обращен.
Начальные процессы жизненного цикла состоят из категорий процессов поставщик - заказчик и инжиниринга.
Категория процесса поставщик - заказчик состоит из процессов, на которые непосредственно воздействует заказчик, разработка поддержки и перехода ПО заказчику, и предусматривают корректное функционирование и использование программного продукта и/или услуг.
Категория процесса инжиниринга состоит из процессов, которые непосредственно определяют, осуществляют или поддерживают программный продукт, его отношение к системе и его документации потребителя (заказчика).
Поддерживающие процессы жизненного цикла состоят из категории процесса поддержки.
Категория процесса поддержки состоит из процессов, которые могут использоваться любым из других процессов (включая другие поддерживающие процессы ) в различных точках жизненного цикла ПО.
Организационные процессы жизненного цикла состоят из категорий процессов управления и организации.
Категория процесса управления состоит из процессов, которые содержат методы общего характера, которые могут использоваться любым, кто управляет любым типом проекта или процессом внутри жизненного цикла программного обеспечения.
Категория процесса организации состоит из процессов, которые устанавливают бизнес - цели организации и разрабатывают (развивают) процесс, продукт и активные ресурсы, которые, когда используется проектами в организации, помогут организации достигнуть ее бизнес - целей.
Категории процессов и процессы обеспечивают группирование типов деятельности. Каждый процесс в эталонной модели описан в терминах утверждения цели. Эти утверждения включают в себя уникальные функциональные цели процесса, которые подтверждаются в конкретной среде. Утверждение цели включает дополнительный материал, определяющий выходы успешной реализации процесса. Соответствие цели процесса представляет первый шаг в формирование возможности процесса.
Эталонная модель не определяет как, или в каком порядке, элементы утверждений цели процесса должны быть достигнуты. Цели процесса будут достигнуты в организации через различные действия более низкого уровня, задачи и методики, выполняемые, чтобы произвести рабочий продукт. Эти выполняемые задачи, действия и методики, а также характеристики произведенных рабочих продуктов, являются показателями, которые демонстрируют, достигнута ли цель конкретного процесса.
Развитие возможности процесса характеризуется в терминах атрибутов процесса, сгруппированных в уровни возможности. Атрибуты процесса являются признаками процесса, которые могут быть оценены по шкале достижения, обеспечивая меру возможности процесса. Атрибуты применимы ко всем процессам. Каждый атрибут процесса описывает аспект полной возможности управления и улучшения эффективности процесса в достижении его целей и содействующего бизнес - целям организации.
Уровень возможности характеризуется набором атрибутов, которые работают вместе. Каждый уровень обеспечивает главное расширение возможности выполнения процесса. Уровни составляют рациональный путь развития через усовершенствование возможности любого процесса.
Есть шесть уровней возможности в эталонной модели.
Уровень 0: Незавершенный. Общая неудача в достижении цели процесса. Имеются нелегко идентифицированные рабочий продукт или выходы процесса.
Уровень 1: Выполняемый. Цель процесса, в общем, достигнута. Достижение не может строго планироваться и отслеживаться. Персонал организации осознает, что процесс должен выполняться, и имеется общее согласие, что этот процесс выполняется, как требуется и когда требуется. Имеются определенные рабочие продукты процесса, и они свидетельствуют в пользу достижения цели.
Уровень 2: Управляемый. Процесс вырабатывает рабочие продукты согласно определенным процедурам, планируется и отслеживается. Рабочие продукты соответствуют конкретным стандартам и требованиям. Основное различие от Выполняемого уровня в том, что при выполнении процесса теперь вырабатываются рабочие продукты, которые полностью требования к качеству в пределах определенного промежутка времени и выделенного ресурса.
Уровень 3: Установленный. Процесс выполняется и управляется, используя определенный процесс, основанный на хороших принципах инжиниринга программного обеспечения. Индивидуальные реализации процесса используют документирующие процессы, утвержденные, приспособленные версии стандарта в достижении выходов определенного процесса. Ресурсы, необходимые для установления определения процесса - также на месте. Основное отличие от Управляемого уровня в том, что процесс Установленного уровня использует определенный процесс, который способен достигнуть своих выходов.
Уровень 4: Предсказуемый. Определенный процесс, на практике, последовательно выполняется в пределах определенных ограничений и достигает определенных целей. Подробные меры выполнения процесса собраны и проанализированы. Это ведет к количественному пониманию возможности процесса и улучшенной способности предсказать выполнение. Выполнение процесса объективно управляется. Качество рабочих продуктов количественно известно. Основное отличие от Установленного уровня в том, что определенный процесс теперь выполняется последовательно внутри определенных ограничений, чтобы достигнуть своих определенных выходов.
Уровень 5: Оптимизирующий. Выполнение процесса оптимизируется, чтобы достичь текущие и будущие деловые потребности. Процесс достигает повторяемости при достижении определенных бизнес - целей. Количественная эффективность процесса и цели эффективности для выполнения установлены, базируются на бизнес - целях организации. Непрерывный процесс, контролирующий эти цели, позволяет получать количественную обратную связь, и усовершенствование достигнуто анализом результатов. Основное отличие от Предсказуемого уровня в том, что определенные и стандартные процессы теперь динамически изменяются и адаптируются, чтобы эффективно достичь текущие (актуальные) и будущие бизнес - цели.
Естественно, эталонная модель не может использоваться как основа для проведения надежных и непротиворечивых оценок возможности процесса, так как уровень детализации не достаточен. Описания цели процесса и атрибутов возможности в эталонной модели необходимо поддерживать исчерпывающим набором показателей выполнения процесса и его возможности. Таким образом, будет возможен непротиворечивый рейтинг возможности процесса.
Измерение процесса
В этом подразделе приводиться классификация процессов, принятых в организациях, занимающихся разработкой, эксплуатацией, приобретением, поставкой и поддержкой функционирования ПО. Классификация распознает пять категорий процессов, которые содержат все процессы. Категории и их процессы сопоставимы с теми процессами, которые определены в проекте стандарта ИСО/МЭК 12207, Информационная технология - Жизненный цикл процесса ПО, рассмотренного нами в разделе 2.
Как было отмечено выше, в эталонной модели процессы объединяются в три группы и пять категорий процессов:
начальные процессы жизненного цикла включают категории процесса инжиниринга и поставщик - заказчик;
поддерживающие процессы жизненного цикла включают категории процесса поддержки;
организационные процессы жизненного цикла включают категории процесса управления и организации.
Описание каждой категории процессов включает характеристику процессов, которые он содержит, сопровождающееся списком имен процессов.
Индивидуальные процессы описаны в терминах шести компонентов.
Идентификатор процесса. Идентифицирует категорию и последовательный номер внутри этой категории. Схема нумерации различается между процессами верхнего уровня и процессами второго уровня. Идентификатор состоит из двух частей: сокращения категории (например, ENG для категории процесса инжиниринга) и номер (например, CUS. 1 обозначает Процесс Приобретения и CUS. 1.2 обозначает процесс второго уровня, Процесс Выбора Поставщика, который является составляющим (компонентным) процессом Процесса Приобретения).
Имя процесса. Описательная фраза, которая выделяет принципиальное свойство процесса (например, Выбор Поставщика).
Тип процесса. Имеется 3 типа процессов верхнего уровня (базисный, расширенный, новый) и 2 процесса второго уровня (компонентный, расширенный), которые имеют следующее отношение к процессам ИСО/МЭК 12207. Новые процессы дополнительны к тем, что определены в ИСО/МЭК 12207. Базисные процессы идентичны в предназначении процессам ИСО/МЭК 12207. Расширенные процессы дополняются на существующем процессе ИСО/МЭК 12207. Компонентные процессы группирует одно или большее количество действий ИСО/МЭК 12207 из того же самого процесса. Расширенные компонентные процессы группируют одно или большее количество действий ИСО/МЭК 12207 из того же самого процесса и включают дополнительный материал.
Цель процесса. Материал, который указывает цель процесса, устанавливающего общие цели выполнения процесса на верхнем уровне. Необязательный дополнительный материал может быть включен, чтобы далее определить утверждение цели.
Результаты процесса. Список описаний результатов процесса.
Примечания процесса. Необязательный список информативных примечаний относительно процесса и его отношения к другим процессам.
Для примера, приведем несколько процессов из каждой категории процесса.
CUS.1 Процесс Приобретения
Базисный процесс
Цель Процесса Приобретения состоит в том, чтобы получить продукт и/или услугу, которое удовлетворяет потребность, выраженную заказчиком (клиентом). Процесс начинается с определения потребности заказчика и требуемых результатов с принятием продукта и/или услуги, необходимого заказчиком. В результате успешной реализации процесса:
- будет разработан контракт, который ясно выражает ожидания, обязанности и обязательства, как заказчика, так и поставщика;
- будет произведен продукт и/или услуга, что удовлетворит установленную потребность заказчика;
- приобретение будет проверено таким образом, чтобы определенные ограничения как, например, стоимость, план и качество были выполнены.
CUS.1.1 Процесс Подготовки Приобретения
Компонентный процесс CUS.1 - Процесса Приобретения
Цель Процесса Подготовки Приобретения состоит в том, чтобы установить потребности и цели приобретения. В результате успешной реализации процесса:
- будет установлена потребность в приобретении, разработке или расширении системы, программного продукта или процесса разработки ПО;
- будут сформулированы системные требования;
- будет разработана стратегия приобретения;
- будут определены приемочные критерии.
ENG.1 Процесс Разработки
Базисный процесс
Цель процесса Разработки состоит в том, чтобы трансформировать согласованный набор требований в функциональный программный продукт или программную систему, которые удовлетворяют установленным потребностям заказчика. В результате успешной реализации процесса:
- будет разработан программный продукт или программная система;
- будут разработаны промежуточные рабочие продукты, что показывает, что конечное изделие основывается на согласованных требованиях;
- будет установлена непротиворечивость между требованиями программного обеспечения и проектами программного обеспечения;
- данные тестирования будут показывать, что конечный продукт встречает согласованные требования;
- конечный продукт будет установлен в целевую среду и принят заказчиками.
ПРИМЕЧАНИЕ: Согласованные требования можно обеспечивать операцией процесса Приобретения (CUS. 1) или Процесса Установления Требований (CUS. 3).
ENG.1.1 Процесс Разработки и Анализа Системных Требований
Компонентный процесс ENG.1 - Процесса Разработки
Цель Процесса Разработки и Анализа Системных Требований состоит в том, чтобы установить системные требования (функциональные и нефункциональные) и архитектуру, идентифицируя, какие системные требования должны быть распределены к каким элементам системы и в какой версии. В результате успешной реализации процесса:
- будут разработаны системные требования, что соответствует установленным потребностям заказчика;
- будет предложено решение, идентифицирующее основные элементы системы;
- согласованные требования будут распределены каждому из основных элементов системы;
- будет разработана стратегия версии, определяющая приоритет для выполнения системных требований;
- системные требования будут одобрены и модифицированы, как и требуется;
- требования, предложенное решение и их связи будут сообщены всем заинтересованным сторонам.
SUP.1 Процесс Документирования
Расширенный Процесс
Цель Процесса Разработки ALIGN="JUSTIFY"Документации состоит в том, чтобы разработать и поддержать документы, которые записывают информацию, произведенную процессом или действием. В результате успешной реализации процесса:
- будет разработана стратегия, идентифицирующая документы, которые будут произведены в течение жизненного цикла программного продукта;
- будут определены стандарты, к которые должны обращаться за разработка документов;
- все документы, которые будут произведены процессом или проектом будут идентифицированы;
- содержание и цель всех документов будет определена, рассмотрена и одобрена;
- все документы будут разрабатываться и издаваться в соответствии с определенными стандартами;
- все документы будут поддерживаться в соответствии с определенными критериями.
ПРИМЕЧАНИЕ - процесс поддерживает исполнение атрибута процесса 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
Инфраструктура (базисный)