вав. Носов_П.П._ивт-м1-2021_ипз. Российский государственный социальный университет Факультет информационных технологий ипз по дисциплине Управление программноаппаратными средствами

Название	Российский государственный социальный университет Факультет информационных технологий ипз по дисциплине Управление программноаппаратными средствами
Дата	29.11.2021
Размер	1.16 Mb.
Формат файла
Имя файла	Носов_П.П._ивт-м1-2021_ипз.docx
Тип	Документы #286104

Российский государственный социальный университет
Факультет информационных технологий

ИПЗ

по дисциплине «Управление программно-аппаратными средствами»

ФИО студента	Носов Павел Павлович
Направление подготовки	Информатика и вычислительная техника
Группа	ИВТ-М-1-Д-2021-1

Москва 2021

Вопросы по лекциям:

Что такое цепочка добавленной стоимости? Как выглядит примерная цепочка добавленной стоимости для ИТ-организации?
В чем разница между основными и вспомогательными процессами? Может ли процесс быть одновременно основным и вспомогательным?
Что такое сеть добавленной стоимости?
Какова роль ИТ-стандартов в управлении ИТ?
Чем отличается стандарт ГОСТ Р ИСО/МЭК 12207 от ГОСТ 34 (одно предложение)?
Какова структура ГОСТ Р ИСО/МЭК 12207?
Какие конкретные критерии и методы оценки поставщика в процессе заказа предлагает ГОСТ Р ИСО/МЭК 12207?
В чем разница между процессами аттестации, верификации, аудита и обеспечения качества?
Что такое адаптация в терминологии ГОСТ Р ИСО/МЭК 12207?
Каковы практические недостатки ГОСТ Р ИСО/МЭК 12207 по сравнению с ГОСТ 34?
В чем состоит задача внедрения ГОСТ Р ИСО/МЭК 12207 согласно ГОСТ Р ИСО/МЭК 15271? Чем отличается внедрение от применения стандарта?
Какова структура ГОСТ Р ИСО/МЭК 15271?
Как выглядит стратегия внедрения ГОСТ Р ИСО/МЭК 12207 в ГОСТ Р ИСО/МЭК 15271?
Каковы причины внедрения ГОСТ Р ИСО/МЭК 12207 в изложении ГОСТ Р ИСО/МЭК 15271?
Какова цель стандарта ГОСТ Р ИСО/МЭК 16326?

Ответы на вопросы:

Цепочка добавленной стоимости является одной из основ процессорного подхода к управлению ИТ. Смысл цепочки добавленной стоимости – в разграничении основных и вспомогательных групп бизнес-процессов организации. Цепочка добавленной стоимости для ИТ-организации выглядит, примерно так:
Разница между ними заключается в том, что основные группы процессов добавляют стоимость производимому бизнесом продукту или услуге, вспомогательные - нет. Из рисунка ниже, мы видим, что «Управление ИТ» находится в вспомогательных процессах:

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

ИТ-организация, как правило, взаимодействует с рядом внешних контрагентов. Участие внешних контрагентов в процессах ИТ-организации порождает сеть добавленной стоимости. Сеть добавленной стоимости демонстрирует важность для ИТ-организации процессов управления взаимоотношениями с контрагентами. Отсюда можем сделать вывод, что сеть добавленной стоимости – это участие внешних контрагентов в процессах ИТ-организации.
Роль ИТ-стандартов в управлении ИТ заключается в том, чтобы повысить результативность и эффективность основных и вспомогательных процессов. Сделать это можно с помощью эталонных моделей, которые существуют главным образом в форме международных стандартов, разрабатываемых международной организацией по стандартизации ( ISO3 ) и другими авторитетными международными и национальными организациями. Важно понимать, что эталонная модель процессов не является идеальным образцом для подражания, применимым во всех случаях жизни, а представляет лишь усредненный опыт, который признан профессиональным сообществом и, стало быть, может оказаться полезным при решении задачи повышения эффективности управления ИТ в конкретной организации.
В первую очередь в ориентированности на процессы, современном взгляде на управление качеством, проектном подходе к деятельности по созданию информационных систем.
Методологическая основа ГОСТ Р ИСО/МЭК 12207 - разбиение процессов на группы, которых в стандарте вводится три:
1)Основные. Это процессы, непосредственно относящиеся к жизненному циклу информационной системы. Можно считать, что это производственные процессы организации.
2) Вспомогательные. Это процессы, предназначенные для поддержки основных процессов. Сами по себе эти процессы организации не нужны - только в связи с основными процессами, которые они обслуживают. Несколько процессов из этой группы связано с управлением качеством. 3)Организационные. Это общекорпоративные процессы, такие как "Обучение" или "Управление". Эти процессы существуют в организации независимо от того, как организовано производство и как устроены вспомогательные процессы.

Предлагается осуществлять надзор за поставщиком. Он заключается в следующем:

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

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

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

Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора. Процесс может "выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона (ревизующая) проверяет другую сторону (ревизуемую)".

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

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

Процессом адаптации называется "процесс применения положений настоящего стандарта к условиям реализации конкретного программного проекта". Описан этот процесс в том же стиле, что и остальные процессы. Адаптация - обязательная деятельность в ходе применения стандарта на практике.
Основные практические недостатки в том, что наличие процесса адаптации подразумевает, что ГОСТ Р ИСО/МЭК 12207 сначала внедряется в организации в целом, а затем для каждого проекта из него "выкраивается" подмножество необходимых процессов. О том, как организовать внедрение стандарта в организации, ГОСТ Р ИСО/МЭК 12207 умалчивает. Особо отмечается сложность организации внедрения стандарта. Неслучайно следом за ГОСТ Р ИСО/МЭК 12207 был разработан специально посвященный задаче его внедрения стандарт ГОСТ Р ИСО/МЭК 15271-02 (ГОСТ 15271, 2002), который называется "Руководство по применению ГОСТ Р ИСО/МЭК 12207".
Согласно стандарту, является "типовой метод внедрения, которого следует придерживаться при внесении изменений в деятельность организации или проект". Стратегия реализуется как проект, состоящий из обязательных к выполнению шагов, описанных неформально и вне всякой связи с процессами организации. Основным отличием внедрения от применения является то, что внедрение стандарта это постоянно выполняемый процесс.
Стандарт ГОСТ Р ИСО/МЭК 15271 состоит из 8 разделов и 4 Приложений. Содержательные разделы называются так (нумерация взята из текста):

 4. Основные концепции развития ГОСТ Р ИСО/МЭК 12207.

 5. Внедрение ГОСТ Р ИСО/МЭК 12207.

 6. Применение в проектах.

 7. Применение в организациях.

 8. Прикладное применение модели жизненного цикла системы.

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

разработка плана внедрения;
практическое применение ГОСТ Р ИСО/МЭК 12207;
проведение сопровождения пилотного проекта(ов);
формализация метода внедрения;
утверждение метода внедрения.

Причины, по которым ГОСТ Р ИСО/МЭК 12207 внедряют в организации, могут быть следующими:

проверка совершенства существующего метода. Это обычно имеет место, когда метод был разработан самой организацией или ею был выбран и изменен существующий метод;
практическое применение данного метода для предотвращения риска, связанного с выходом на новые секторы рынка с более жесткими требованиями, связанными с потенциальным риском;
разработка нового метода, например для удовлетворения потребностям новой организации. Тем самым могут быть охвачены организации, созданные путем слияния или делового сотрудничества. Это может быть необходимо для сопровождения некоторых моделей процессов обеспечения конкретных работ;
управление внедрением новой технологии, например автоматизация ручных процессов или изменение методов, используемых при внедрении программного продукта. ГОСТ Р ИСО/МЭК 12207 устанавливает критерии, которые могут быть использованы для контроля совершенства соответствующего метода до или после изменения технологии;
оценка внутренних возможностей стороны с точки зрения удовлетворения критериям договора, например в качестве стороны, участвующей в конкурсном (тендерном) процессе;
определение контрольных этапов, при реализации которых могут быть разработаны более совершенные программы, например проведение аудита в соответствии с ГОСТ Р ИСО/МЭК 12207 и использование самого процесса усовершенствования".

В целом стандарт ГОСТ Р ИСО/МЭК 15271 производит впечатление сугубо вспомогательного по отношению к ГОСТ Р ИСО/МЭК 12207 документа, страдающего приблизительностью и обилием общих мест. Цель стандарта ГОСТ Р ИСО/МЭК 15271 показать направление мысли специалистов в сфере управления ИТ. Он демонстрирует, куда и как развиваются современные стандарты.

Цель стандарта ГОСТ Р ИСО/МЭК 16326 "Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом" (ГОСТ 16326, 2002) - формализовать процесс применения ГОСТ Р ИСО/МЭК 12207. Он демонстрирует попытку объединить процессы жизненного цикла из ГОСТ Р ИСО/МЭК 12207 с процессами управления проектами из популярного методического справочника PMBOK1 (PMBOK, 2009) и стандарта ISO 10006 (русская версия стандарта содержится в (ГОСТ 1

0006, 2005)).

Вопросы по лекциям:

В чем состоит назначение CMM?
Как выглядят уровни зрелости CMM? В чем их смысл?
Что такое СППО?
Чем подход к улучшению процессов, предлагаемый CMM, отличается от подхода, базирующегося на внедрении процессных стандартов (например, ГОСТ Р ИСО/МЭК 12207)?
Какова связь между СППО CMM и процессной моделью ГОСТ Р ИСО/МЭК 12207?
Как можно использовать стандарт IEEE 1074 для повышения уровня зрелости организации? Как можно использовать для этого другие ранее рассмотренные стандарты?
В чем состояла цель проекта SPICE?
Какова структура Отчета SPICE?
Какова структура процессной модели SPICE? Как модель SPICE связана с моделями, представленными в стандартах ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р ИСО/МЭК 15288?
Что такое основные и общие практики? Для чего нужны характеристики?
Чем основные и общие практики отличаются от ключевых практик CMM?
В чем принципиальные отличия модели управления процессами SPICE от модели зрелости CMM?
Какие трудности возникают при практической оценке развитости процессов?
Как в Отчете SPICE выглядит схема улучшения процессов?
В чем состояла цель разработки CMMI?
Какие процессные категории содержит процессная модель CMMI?
В чем отличия процессной модели CMMI от процессных моделей CMM и SPICE?
Что такое процессные области? Какова роль процессных областей в модели CMMI?
Что такое специфические и общие цели? С чем они связываются?
Что такое специфические и общие практики?
Чем CMMI-модель со ступенчатым представлением отличается от модели с непрерывным представлением?
Какова структура CMMI Product Suite?

Ответы на вопросы:

Замечательный практический инструмент, созданный в рамках процессного подхода к описанию деятельности проектной организации, в частности, организации, разрабатывающей информационные системы, демонстрирует методология СММ. CMM расшифровывается как Capability Maturity Model, что по смыслу означает примерно "модель зрелости системы управления". В литературе CMM чаще называют моделью зрелости организации, и я тоже буду следовать этой традиции. История возникновения СММ такова. В конце 80-х гг. прошлого века Министерство обороны США заказало Институту программной инженерии1 Университета Карнеги-Меллон работу по созданию системы критериев для выбора субподрядчиков в проектах разработки программного обеспечения. Работа была закончена в 1991 г., и результатом ее стала модель CMM. Нужно сразу оговориться, что модель не содержит никаких финансовоэкономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем
Уровень 1 "Начальный".

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

Уровень 2 "Повторяемый".

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

Уровень 3 "Определенный".

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

Уровень 4 "Управляемый".

Собираются подробные количественные показатели производственного процесса и качества создаваемого продукта. Как производственный процесс, так и продукты оцениваются и контролируются с количественной точки зрения.

Уровень 5 "Оптимизирующий".

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

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

С точки зрения идеологии CMM, этот стандарт обеспечивает переход организации с первого уровня зрелости на второй. Действительно, он позволяет построить основные процессы управления проектом, позволяющие отслеживать затраты, следить за графиком работ и функциональностью создаваемого программного решения, что и требуется на втором уровне CMM. В IEEE 1074 нет процессов управления субподрядом, да и вообще говорить о буквальном его совпадении с моделью процессов CMM нельзя, но идейное сходство налицо. Таким образом, внедрение модели процессов, предлагаемой IEEE 1074, будет разумным решением в направлении улучшения процессов управления ИТ для организаций, находящихся на первом уровне зрелости. Для того чтобы улучшить процессы управления ИТ организации, находящейся на втором уровне зрелости, необходимо, согласно CMM, реализовать семь групп ключевых процессов, соответствующих третьему уровню зрелости: • координация производственного процесса организации; • определение производственного процесса организации; • программа обучения; • интегрированное управление разработкой ПО; • инженерия разработки программного продукта; • межгрупповая координация; • экспертные оценки. Идея состоит в том, что роль стандартного производственного процесса организации при определенных допущениях может играть совокупность процессов, описанная в ГОСТ Р ИСО/МЭК 12207
В 1993 г. с одобрения ISO была создана международная Проектная Организация SPICE1 (SPICE), которая к 1995 г. подготовила девять документов под общим названием "Оценка процессов, связанных с программным обеспечением" (Software Process Assessment), где рассматриваются все задачи, возникающие при проведении оценки, от построения рейтингов процессов до обучения участников проекта. Эти документы, имевшие статус проекта стандарта ISO, впоследствии действительно составили стандарт ISO/IEC TR 15504 - CMM "Information Technology. Process Assessment". В 2001 г. был опубликован русский перевод стандарта фирмы Ай-Ти (Ай-Ти, 2001), а в 2009 г. подготовлен аутентичный перевод, получивший статус стандарта ГОСТ Р ИСО/МЭК 15504 "Информационные технологии. Оценка процессов" (вводится в действие с 2010 г.). С появлением стандарта ISO название "SPICE" перешло к организации пользователей разработки группы SPICE, которая продолжает существовать и с 2000 г. проводит ежегодные пользовательские конференции.

Вводная часть. Описывает контекст деятельности по оценке и улучшению процессов и вводит пять категорий процессов.
2. Модель управления процессами. Определяет шесть уровней развитости процесса. Включает описания всех общих практик для всех уровней развитости и всех основных практик для всех процессов из процессных областей. Модель управления процессами принципиально отличается от модели CMM, хотя и имеет с ней общие черты (см. ниже).
3. Оценка процессов. Содержит практические указания по построению профиля (см. ниже) конкретного процесса.
4. Руководство по оценке. Содержит указания по организации проекта оценки, определяет восемь основных этапов проекта, методику выбора экземпляра процесса для оценки, определяет принципы командной работы в проекте. Изложение иллюстрируется примерами.
5. Построение, выбор и использование инструментов оценки. Самая объемная часть стандарта. Содержит практические советы, шаблоны, таблицы и т. П. инструменты для аудитора. Каждый инструмент предназначен для решения совершенно определенной задачи. Например, таблица «Индикаторы управления процессами» дает формальный механизм оценки того, реализованы ли общие практики на определенном уровне. Таблица структурирована по всем уровням и всем общим практикам.
6. Квалификация и обучение аудиторов. Даны описания ролей аудиторов в проекте, представлены профессиональные требования к аудитору, изложены методы оценки квалификации аудиторов.
7. Руководство по использованию оценки с целью улучшения процессов. Содержит рекомендации по инициализации процесса оценки и использованию его результатов в связи с улучшением процессов. Обсуждаются задачи согласования улучшений с бизнес-целями организации, культурные и коммуникационные аспекты улучшения процессов.
8. Руководство по использованию при определении развитости процессов поставщика. Содержит соображения по выполнению потребителем оценки процессов потенциального поставщика и вытекающих отсюда рисков. Может использоваться самим поставщиком для оценки того, удовлетворяет ли он требованиям потребителя.
9. Словарь.

Формальная структура модели процессов следующая. Процессы состоят из основных практик.

Наконец, определяется шесть уровней развитости процессов. Каждый уровень полностью определяется своим набором характеристик. Характеристики нумеруются так: "номер уровня, номер характеристики на уровне".

Во-первых, множество процессов организации полностью определено и не меняется в связи с развитием организации. В качестве такого множества взята модель процессов, близкая к той, которую предлагает стандарт ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207), но расширенная процессами управления проектами (таблица соответствий приведена в Приложении E к части 2 Отчета). В стандарте ISO/IEC 15504 (Ай-Ти, 2001) собственная модель процессов была отчасти перегруппирована и расширена по сравнению с эталонной моделью ГОСТ Р ИСО/МЭК 12207 за счет добавления процессов административного управления рисками, административного управления качеством, процесса организационных установок и некоторых других. Позже стандарт был сделан независимым от конкретной модели процессов и просто ссылался на эталонные модели ISO/IEC 12207 и ISO/IEC 15288. Вместо зрелости8 производственного процесса организации в целом вводится понятие развитости9 каждого процесса в отдельности. Разные процессы могут иметь разные уровни развитости; понятие зрелости организации отсутствует. Для того чтобы не придумывать для каждого процесса свои критерии развитости, была определена шкала из шести независимых от процессов уровней, которые характеризуют не процессы, а организацию в целом. Фактически уровни определяют способности организации по управлению процессами. Довольно искусственное построение CMM, где ключевые практики входили не в процессы, а в разделы, и на каждом уровне содержание разделов было уникально (сохранялись только их названия) заменено в модели SPICE гораздо более простым. Теперь основные практики составляют собственно процессы, а общие - описания уровней. То, что общие практики сгруппированы в характеристики - не более чем удобная нотация. Описания уровней полностью независимы от процессов, описания процессов, в свою очередь, не связаны с уровнями, принадлежность процесса к категории имеет только иллюстративный смысл.

Основные практики процесса обеспечивают достижение его цели и генерируют результаты процесса (в Отчете используется термин work products, который обозначает и промежуточные, рабочие результаты). Выполнение процесса - это и есть выполнение его основных практик. Кроме того, имеются общие практики, характеризующие не процесс, а организацию. Общие практики отражают управленческие действия, направленные на реализацию процесса или на управление процессом. Общие практики в равной степени применимы ко всем процессам. Общие практики объединяются в характеристики7 . Содержательно объединение ничего нового не дает, а только группирует практики, близкие по целям управления.
В основу CMM была положена точка зрения, согласно которой уровень зрелости организации характеризуется группой ключевых процессов, причем на каждом уровне зрелости эта группа своя. В ходе развития организации и перехода ее на более высокие уровни зрелости ключевые практики, составляющие группу, и сами группы изменяются. Группы ключевых процессов, соответствующие каждому уровню, были детально описаны. Часть ключевых практик группы определяла собственно выполняемые процессы, а остальные ключевые практики описывали, насколько эти процессы внедрены в практику организации. Для того чтобы подчеркнуть это различие, ключевые практики на каждом уровне группировались в одинаковые разделы с "говорящими" названиями, по которым можно было судить о назначении входящих в раздел практик.
Во-первых, множество процессов организации полностью определено и не меняется в связи с развитием организации. В качестве такого множества взята модель процессов, близкая к той, которую предлагает стандарт ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207), но расширенная процессами управления проектами (таблица соответствий приведена в Приложении E к части 2 Отчета). В стандарте ISO/IEC 15504 (Ай-Ти, 2001) собственная модель процессов была отчасти перегруппирована и расширена по сравнению с эталонной моделью ГОСТ Р ИСО/МЭК 12207 за счет добавления процессов административного управления рисками, административного управления качеством, процесса организационных установок и некоторых других. Позже стандарт был сделан независимым от конкретной модели процессов и просто ссылался на эталонные модели ISO/IEC 12207 и ISO/IEC 15288. Вместо зрелости8 производственного процесса организации в целом вводится понятие развитости9 каждого процесса в отдельности. Разные процессы могут иметь разные уровни развитости; понятие зрелости организации отсутствует. Для того чтобы не придумывать для каждого процесса свои критерии развитости, была определена шкала из шести независимых от процессов уровней, которые характеризуют не процессы, а организацию в целом. Фактически уровни определяют способности организации по управлению процессами. Довольно искусственное построение CMM, где ключевые практики входили не в процессы, а в разделы, и на каждом уровне содержание разделов было уникально (сохранялись только их названия) заменено в модели SPICE гораздо более простым. Теперь основные практики составляют собственно процессы, а общие - описания уровней. То, что общие практики сгруппированы в характеристики - не более чем удобная нотация. Описания уровней полностью независимы от процессов, описания процессов, в свою очередь.
Кажущаяся простота модели, однако, исчезает при попытке применить ее на практике. Продолжим наш пример. Во-первых, что делать, если не все результаты процесса верифицируются, т. е. общая практика 2.3.2 реализована не полностью? Пусть, например, стратегия приобретения (промежуточный результат, порождаемый основной практикой CUS.1.3) верифицируется (проверяется на соответствие определенным корпоративным стандартам), а потребность (CUS.1.1) - нет (например, такого корпоративного документа не существует). Будет ли в этом случае процесс относиться к уровню 2? Можно придумать и более сложные случаи, когда некоторые основные практики будут удовлетворять требованиям более чем двух уровней, и вопрос правильного позиционирования процесса станет еще более запутанным. Во-вторых, в реальной организации сами процессы могут отличаться от предлагаемых SPICE, т. е. основные практики могут отличаться от стандартных. Как поступать в этом случае? В-третьих, общие практики могут быть представлены далеко не полностью или отличаться от стандартных. Например, качество может оцениваться без использования точных критериев (отсутствует характеристика 4.1). Как в этом случае идентифицировать уровни развитости? В-четвертых, процессы реализуются в виде экземпляров, возникающих в проектах. Как анализировать процесс, если разные его экземпляры работают по-разному?
Цель работы состояла в том, чтобы, проанализировав и обобщив опыт разработки СММ-подобных моделей для разных видов деятельности, создать интегрированную методику оценки развитости и совершенствования процессов организации.
Управление процессами, управление проектами, разработка, сопровождение. Концептуальная модель CMMI дает несколько тривиальных рекомендаций по выбору совокупности процессных областей для включения их в CMMI-модель, но оставляет окончательное решение за организацией. Н
Как и в СММ и в SPICE, индивидуальные процессы отсутствуют; они "рассыпаны" на практики, которые, выполняясь в совокупности, достигают связанных с процессной областью целей. Структурно CMMI-модель организована похоже на модель SPICE. Объект верхнего уровня в CMMI-модели - процессная область. Специфические практики - "кирпичики", из которых составляются специфические для данной процессной области процессы. Вообще говоря, у разных процессных областей специфические практики разные. В идеале для достижения специфической цели (целей) процессной области необходимо, чтобы все специфические практики существовали, были устойчивыми, стабильными, эффективными, и это будет означать, что в данной процессной области организация достигла совершенства. В реальности, однако, дело может обстоять иначе: часть практик может отсутствовать совсем, часть - возникать и исчезать, часть - работать неэффективно и т. д. Для того чтобы как-то структурировать возможные ситуации, вводятся уровни развитости и связываются они с процессными областями через практики.
Процессная область - сложный объект, связанный с другими компонентами CMMI-модели. Цели процессной области достигаются путем выполнения входящих в нее специфических практик. Практики, работающие на достижение одной и той же цели процессной области (их может быть несколько), могут находиться на разных уровнях развитости, соотнесенных с процессной областью. Общие9 цели связываются с процессной областью косвенно через уровни развитости, для которых они определены. Общие цели достигаются путем выполнения общих практик.

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

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

21. Непрерывным называется такое представление CMMI-модели, где уровни развитости связываются с процессными областями, т. е. фактически с процессами. Ступенчатое представление соотносит уровни (там они называются уровнями зрелости) с организацией в целом. До сих пор рассматривались только CMMI-модели с непрерывным представлением. Разница между моделями - в их назначении. Модель с непрерывным представлением предназначена для выявления и анализа порядка выполнения действий по совершенствованию процессных областей (и в конечном итоге организации в целом). Она используется для внутренних целей организации и включает профили развитости процессов. Модель со ступенчатым представлением подсказывает пути совершенствования управленческих практик в организации и предназначена в основном для сравнения с другими организациями, а также для перехода от SWCMM к CMMI. Фактически это модель зрелости организации, аналогичная той, что была предложена в CMM. Здесь показано, как построить ее по модели с непрерывным представлением

22. Концептуальная модель CMMI постоянно развивается и, как утверждают некоторые авторы, в отличие от стандарта ISO/IEC 15504 пользуется все большей популярностью. С помощью Концептуальной модели версии 1.2 в 2006 г. была создана CMMI-модель для процессов разработки (CMU-SEI, 2006), затем появились CMMI-модель для процессов приобретения (CMU-SEI, 2007) и CMMI-модель для услуг (CMU-SEI, 2009). Все эти модели имеют в своей основе общую часть, так называемую CMMI Model Foundation (CMF), содержащую описание базовых 16 процессных областей. Новые модели включают дополнительные специфические процессные области (так, например, CMMI для услуг содержит 24 процессные области), а вся их совокупность называется теперь CMMI v.1.2 Product Suite.