
Презентация Лекция 08, 09. Управление качеством. CMM.ppt
- Количество слайдов: 78
В. В. Шилов ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ Управление качеством Москва, 22 и 29 апреля 2016 года
Функциональные области управления проектами 2
Качество товара и качество услуги Качество – это свойство товара или услуги наиболее полно удовлетворять требованиям и пожеланиям потребителя. Но это понятие “качественное”. Можно ли качество измерить? Наиболее общим является подход, при котором вводятся понятия: q Ценность изделия – способность удовлетворять потребности. q Качество изделия – соответствие между свойствами изделия и его ценностью. q Мера качества – соотношение ценности и стоимости. 3
Переход от обеспечения качества к управлению качеством Цель – не обнаружить и изъять негодные изделия до их отгрузки покупателю, а увеличить выход годных изделий в процессе производства. Основные этапы этого перехода: q Управление процессами – переход от контроля к управлению отдельными процессами. q Управление производством – переход от управления отдельными процессами к управлению производством в целом. Главная идея перехода от контроля к управлению качеством – качество продукта должно обеспечиваться качеством процесса его изготовления. 4
Armand Vallin Feigenbaum (1922 -2014) TQM (Total Quality Management), 1957 год 5
Принципы TQM 1. Ориентация организации на потребителя (Customer-Focused Organization). 2. Лидерство (Leadership). 3. Вовлечение персонала (Involvement of People). 4. Процессный подход (Process Approach) 5. Системный подход к административному управлению (System Approach to Management) 6. Непрерывное усовершенствование (Continual Improvement) 7. Основанный на фактах подход к принятию решений (Factual Approach to Decision Making) 8. Взаимовыгодные отношения с поставщиками (Mutually beneficial supplier relationship) 6
ISO 9000 Принципы TQM составляют методологическую основу ISO 9000 – серии международных стандартов, регламентирующих организацию системы управления качеством. Стандарты серии ISO 9000 универсальны, т. е. применимы к любым предприятиям независимо от сферы деятельности, формы собственности, размеров предприятия. Первая версия ISO 9000 вышла в 1987, третья – в 2000 г. Позднее – ISO 9000: 2005, ISO 9001 (СМК. Требования), ISO 9004 (СМК. Руководство для улучшения характеристик). Последний – ISO 9001: 2015. Версия ISO 9000 2000 года содержит 5 базовых стандартов. Позже стали выходить различные методические руководства по применению ISO 9000: 2000 к различным видам деятельности. Для применения в программной инженерии вышел стандарт ISO/IEC 90003, Guidelines for the Application of ISO 9001: 2000 7 to Computer Software, 2004.
ISO 9000 – структура документов системы качества Система управления качеством поддерживается следующей структурой документов: § Заявление о политике и целях в области качества. § Руководство по качеству. § Документированные процедуры, требуемые настоящим международным стандартом. § Документы, необходимые организации для обеспечения эффективного планирования и осуществления процессов и управления ими (положения о подразделениях, должностные инструкции, регламенты, технологические инструкции. . . ). § Записи о качестве. 8
ISO 9000 – структура документов системы качества Заявление о политике и целях – небольшой по объему документ (1 -2 листа), отражающий следующие позиции: § Общие намерения и направления деятельности организации в области качества, официально сформулированные высшим руководством. § Не должно быть просто декларацией – цели должны быть конкретными, достижимыми, проверяемыми. § Должно определять приоритеты, содержит 3 -4 наиболее важные цели. Заявление о политике и целях в области качества 9
ISO 9000 – структура документов системы качества Руководство по качеству – более детальный документ (20 -50 листов), содержащий описание всей системы качества в целом. Его структура должна соответствовать структуре стандарта ISO 9001 или же должна быть представлена таблица соответствия разделов руководства и стандарта. Руководство по качеству 10
ISO 9000 – структура документов системы качества Структура стандарта ISO 9001 включает: Система менеджмента качества (Общие требования. Требования к документации). Ответственность руководства (Обязательства руководства. Ориентация на потребителя. Политика в области качества. Планирование. Ответственность, полномочия и обмен информацией. Анализ со стороны руководства). Менеджмент ресурсов (Обеспечение ресурсами. Человеческие ресурсы. Инфраструктура). Производственная среда (Процессы жизненного цикла продукции. Планирование процессов жизненного цикла продукции. Процессы, связанные с потребителями. Проектирование и разработка. Закупки. Производство и обслуживание). Измерение, анализ и улучшение (Общие положения. Мониторинг и измерение. Управление несоответствующей продукцией. Анализ данных. Улучшение). Руководство по качеству 11
ISO 9000 – структура документов системы качества Степень документированности (глубина и подробность описания) определяются самой организацией в зависимости от ее размера и вида деятельности, сложности и взаимодействия процессов, компетентности персонала. Обязательными для документирования являются: · процедура по управлению документацией; · процедура по управлению записями о качестве; · процедура по проведению внутренних проверок; · процедура по управлению несоответствующей продукцией; · процедура по корректирующим действиям; · процедура по предупреждающим действиям. Документирование 12
ISO 9000 – структура документов системы качества Состав записей о качестве учитывает специфику предприятия, сложившуюся практику, т. е. предприятие само определяет, в каком виде вести и хранить эти записи. Записи о качестве 13
Система управления качеством Объект управления – “производственная линейка”: Требования заказчика – Создание продукции (оказание услуги) – Выпуск продукции (оказание услуги). Обеспечение качества – элемент общей стратегии организации, опирается на требуемые для этого ресурсы и адекватное управление, организованными в соответствии со стандартом ISO 9001. 2000. В соответствии с этим стандартом, адекватное управление включает: § Выпускаемая продукция контролируется на удовлетворение требований заказчика. § Контроль проводится путем измерений количественных показателей, на основе чего проводится анализ и даются рекомендации по улучшению процессов производства. § Для выполнения этих рекомендаций подключается руководство, которое достигает результата путем управления соответствующими ресурсами. Эта схема работает постоянно и непрерывно. Действует принцип CPI: Continuous Process Improvement – Постоянное Улучшение Процессов. 14
ISO 12207: процессы качества жизненного цикла ПО В стандарте ISO 12207 представлены два процесса, относящиеся к управлению качеством ПО: q Процесс обеспечения качества. q Процесс усовершенствования. Процесс обеспечения качества ISO 12207 имеет целью обеспечение гарантий того, что программные продукты и процессы в жизненном цикле проекта соответствуют установленным требованиям и утвержденным планам. При обеспечении качества могут использоваться результаты других вспомогательных процессов, таких как верификация, аттестация, совместные анализы, аудит и решение проблем. Процесс состоит из следующих работ: подготовка процесса, обеспечение процесса и обеспечение систем качества; эти работы должны быть выполнены в соответствии с разделами ГОСТ Р ИСО 9001, указанными в договоре. Процесс обеспечения качества 15
ISO 12207: процессы качества жизненного цикла ПО Процесс усовершенствования является процессом установления, оценки, измерения, контроля и улучшения любого процесса жизненного цикла программных средств. Процесс состоит из следующих работ: создание процесса усовершенствования, оценка усовершенствуемого процесса и усовершенствование процесса. При создании процесса усовершенствования определяется набор организационных процессов для всех процессов жизненного цикла в соответствии с имеющимся практическим опытом. Эти организационные процессы и их применение в конкретных ситуациях должны быть задокументированы и определен механизм управления процессом усовершенствования при разработке, контроле, управлении и улучшении улучшаемых процессов. Для оценки улучшаемого процесса должна быть разработана, документально оформлена и применена процедура оценки процесса. Должны сохраняться и обновляться отчеты о выполненных оценках процесса. Оценка и анализ улучшаемых процессов должны планироваться и выполняться в установленные сроки. Процесс усовершенствования 16
Что такое качество? Согласно PMBOK, целью любого проекта является удовлетворение требований участников проекта. Обеспечение этой цели достигается путем обеспечения качества проекта. Качество – это целостная совокупность характеристик объекта, относящихся к его способности удовлетворять установленные или предполагаемые потребности. Примеры качества: готовность, безотказность, безопасность, надежность. Управление качеством (в рамках управления проектом) – система методов, средств и видов деятельности, направленных на выполнение требований участников проекта к качеству самого проекта и его продукции. 17
Что такое качество? Качество продукта или услуги – это восприятие потребителем степени соответствия продукта или услуги его ожиданиям. Цель области управления качеством проекта – гарантировать, что проект удовлетворяет целям, ради которых был предпринят (соответствие требованиям). Управление качеством начинается с процесса планирования качества, который генерирует план управления качеством. План используется в процессах обеспечения и контроля качества. Управление качеством / Определение качества 18
Планирование управления качеством План управления качеством должен включать: q Объективную проверку соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям. q Определение отклонений по качеству, выявление их причин, применение мер по их устранению, а также контроль исполнения принятых мер и их эффективности. q Представление высшему руководству независимой информации о несоответствиях, не устраняемых на уровне проекта. 19
Качество проекта Качество включает все деятельности проекта, которые обеспечивают соответствие проекта целям, ради которых он был предпринят. Поэтому управление качеством применимо как к проекту, так и к продукту проекта. Качество критически важно, поскольку озвучивает и фиксирует цели, делает их задокументированными (формализованными). Следовательно, качество – критический компонент управления структурой проекта. Для качества все является измеримым. Управление качеством / Определение качества 20
Управление качеством проекта § Если управление качеством сосредоточено в одном подразделении организации, оно не станет всеобщим. § Менеджер проекта может делегировать аспекты управления качеством. § Менеджер проекта сохраняет за собой окончательную ответственность. 21
Принципы качества (ISO 9000) 1 Ориентация на потребителя 2 Ответственность руководства 3 Вовлечение персонала 4 Процессный подход 5 Системный подход к менеджменту 6 Постоянное улучшение 7 Принятие решений, основанное на фактах 8 Взаимовыгодные отношения с поставщиками Управление качеством / Принципы качества 22
Управление качеством проекта (PMI): подпроцессы § Планирование качества § Обеспечение качества § Контроль качества Управление качеством / Процессы 23
Планирование качества Одна из стадий – определение, какие существующие стандарты относятся к данному проекту, и как им соответствовать. Результатом планирования качества является список всех стандартов качества, которые применимы к проекту. Прилагается список рекомендаций, как будут удовлетворены требования этих стандартов. Управление качеством / Процессы / Планирование качества 24
Процесс планирования качества: входы 1. Политика качества организации. Документ, содержащий принципы того, как организация определяет качество, но не содержащий путей достижения качества. 2. Стандарты и предписания. Список стандартов и предписаний, относимых к данной области или проекту. 3. План управления проектом. Содержит технические детали и другие значимые аспекты, которые могут повлиять на планирование качества. 4. Содержание проекта (scope). Определяет, что должно быть сделано в результате проекта и, следовательно, за чем надо следить в процессах управления качеством. Данный документ является выходом процесса планирования содержания проекта. Управление качеством / Процессы / Планирование качества / Входы 25
Процесс планирования качества: инструменты и технологии Анализ выгода/затраты. Имеет отношение к обсуждению стоимости качества. Цель данного инструмента – сравнить реальную стоимость отсутствия качества с выгодами гарантии качества. Сравнение. Используется для генерации идей для улучшения через сравнение с другими проектами. Наиболее эффективен, когда сравнение происходит с лучшими, а не просто с другими внутренними проектами. Диаграммы. Используются, чтобы показать, как взаимодействуют различные элементы. Существует много типов диаграмм, включая диаграмму причин и следствий. Постановка экспериментов. Используются сценарии “если, то” для определения, какие переменные наиболее влияют на конечный результат проекта. Стоимость качества. 26 Управление качеством / Процессы / Планирование качества / Инструменты
Процесс планирования качества: выходы 1. План управления качеством. Описывает, как команда управления проектом будет проводить политику качества. Должен затрагивать следующие области: n n n n n Контроль проектирования. Контроль документирования. Контроль закупки материалов. Инспекции. Контроль испытаний (тестирования). Контроль над контрольно-измерительным оборудованием. Корректирующие действия. Записи по качеству. Аудиты (план и процедура) 2. Документированные процедуры и рабочие инструкции. Описывают детально процессы и то, как измерить качество процесса, подпроцесса и отдельных совершаемых действий. 3. Контрольные списки процедур контроля качества. Управление качеством / Процессы / Планирование качества / Выходы 27
Обеспечение качества Процесс обеспечения качества – принятие плановых систематических мер, обеспечивающих выполнение всех предусмотренных процессов, необходимых для того, чтобы проект (продукт, услуга) удовлетворял требованиям по качеству. Обеспечение качества является основным подпроцессом управления качеством. Эта деятельность проводится в течение всего проекта. Управление качеством / Процессы / Обеспечение качества 28
Обеспечение качества Функцию обеспечения качества может выполнять команда проекта, руководство исполняющей организации, заказчик или спонсор, другие участники проекта. Для контроля качества проекта проводятся аудиторские проверки, целью которых является выяснение, удовлетворяет ли качество проекта стандартам, установленным в плане обеспечения качества. Процесс обеспечения качества включает методы непрерывного улучшения качества будущих проектов. Знания и опыт по обеспечению качества, накопленные в текущем проекте, должны использоваться при составлении планов обеспечения качества последующих проектов. Управление качеством / Процессы / Обеспечение качества 29
Процесс обеспечения качества: входы План управления качеством. Выход процесса планирования качества. Результаты оценки качества. Информация об исполнении работ. Одобренные запросы на изменение. Изменения, касающиеся методов работы, требований к продукту, требований к качеству, содержанию и расписанию. Проверяются на возможность их влияния на план управления качеством. Контрольные списки качества (метрики качества). Инструкции для проверяющего лица. Результаты контроля качества. Управление качеством / Процессы / Обеспечение качества / Входы 30
Процесс обеспечения качества: инструменты и методы Инструменты и техники планирования качества. Включают анализ прибыли и затрат, сравнения, диаграммы, постановку экспериментов и оценку стоимости качества. Аудиты качества. Экспертная оценка, определяющая, насколько операции проекта соответствуют, и соответствуют ли, установленным в рамках проекта или организации правилам, процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически не оправданных правил, процессов и процедур, используемых в проекте. Типы аудита качества: внутренний / внешний, системный / продукта / процессов / организации, плановый / регулярный, специальный и усложненный. Управление качеством / Процессы / Обеспечение качества / Инструменты 31
Процесс обеспечения качества: выходы Запрошенные изменения. Имеют целью проведение специальных мероприятий по повышению эффективности правил, процедур и процессов в исполняющей организации. Рекомендованные корректирующие действия. Корректирующее действие – это рекомендованное к немедленному исполнению действие, выработанное в результате мероприятий по обеспечению качества (аудита или анализа процессов). Активы организационного процесса (обновления). Обновленные стандарты качества используются в дальнейшем процессе контроля качества. План управления проектом (обновления) подлежит обновлению согласно изменениям в плане управления качеством, выработанным в результате процесса обеспечения качества. Запрошенные изменения в план управления проектом и во вспомогательные планы (добавления, изменения, удаления) подвергаются экспертной оценке и вносятся в соответствующие планы в процессе общего управления изменениями. Управление качеством / Процессы / Обеспечение качества / Выходы 32
Контроль качества – процесс, включающий отслеживание промежуточных результатов проекта, определение их соответствия принятым стандартам и разработку действий для устранения причин, вызывающих отклонения от стандарта. Мониторинг результатов с целью определения их соответствия принятым стандартам качества и определение путей устранения причин, вызывающих неудовлетворительное исполнение. Управление качеством / Процессы / Контроль качества 33
Процесс контроля качества: входы План управления качеством. Выход процесса планирования качества. Результаты оценки качества. Контрольные списки процедур оценки качества. Активы организационного процесса (обновления). Выход процесса обеспечения качества Информация об исполнении работ. Одобренные запросы на изменение. Исправленные методы, исправленное расписание. Управление качеством / Процессы / Контроль качества / Входы 34
Контроль качества: инструменты и техники Инспекции. Включают такие деятельности, как измерения, испытания, тестирования, чтобы удостовериться, что результат удовлетворяет требованиям. Контрольные диаграммы. Статистически определяют верхний и нижний пределы, отраженные по обе стороны от средних значений процесса. Диаграммы: Ишикавы, Парето. Статистическая выборка. Часть контролируемой продукции, позволяющая сделать вывод обо всей продукции данного вида в проекте. Анализ трендов. Цель использования инструментов – зафиксировать результаты или изменения, отобразить их графически, и далее выявить и скорректировать проблемы подходящим способом. Управление качеством / Процессы / Контроль качества / Инструменты 35
Контрольные диаграммы предназначены для определения стабильности протекания процесса и предсказуемости его развития. Используются для определения, вызваны ли наблюдаемые отклонения процесса обычными вариациями в процессе или же свидетельствуют о выходе процесса из-под контроля. Контрольные диаграммы представляют собой графическое отображение взаимодействия переменных процесса в течение процесса и дают ответ на вопрос, находятся ли переменные процесса в рамках установленных пределов. Могут применяться для наблюдения за колебаниями издержек и исполнением расписания, за объемом и частотой изменения содержания проекта, за ошибками в документах проекта или другими результатами управления. Это позволяет определить, насколько действенным является процесс управления проектом. Контрольные диаграммы 36
Диаграмма Ишикавы (диаграмма причинно-следственных связей, диаграмма рыбьего скелета, fish-bone diagram) – отражает возможные причины, влияющие на качество продукта или процесса в проекте. Иллюстрирует связь различных факторов с возможными проблемами или эффектами. Диаграмма Ишикавы 37
Диаграмма Ишикавы 38
Вильфредо Парето (1848 -1923) Гистограмма, упорядоченная по частоте возникновения, которая отображает, какое количество обнаруженных дефектов является следствием причин, относящихся к определенному типу или категории. Закон Парето: относительно малое число причин обычно приводит к большинству проблем или дефектов. Известен как принцип 80/20, согласно которому 80% проблем создается 20% причин. Диаграммы Парето 39
Процесс контроля качества: выходы Результаты контроля качества – результаты мероприятий по контролю качества, переданные в рамках обратной связи в службу обеспечения качества. Базовый план по качеству (обновления). Рекомендованные корректирующие действия – определенные мероприятия, проведение которых вызвано результатами операций по контролю качества. Рекомендованные предупреждающие действия – специальные мероприятия по предупреждению возникновения условий, при которых процессы проекта могут выйти за пределы установленных параметров. План управления проектом (обновления). План управления проектом подлежит обновлению в связи с изменениями в плане управления качеством, вызванными результатами процесса контроля качества. Внесение изменений в проект проводится в соответствии с утвержденными процедурами общего управления изменениями через запрос на изменение. Управление качеством / Процессы / Контроль качества / Выходы 40
Процесс контроля качества: выходы Рекомендованное исправление дефектов – предложения по устранению дефектов. Для формирования набора рекомендаций по исправлению дефектов можно использовать Журнал регистрации дефектов. Активы организационного процесса (обновления), содержащие документацию о накопленных знаниях. Утвержденные результаты поставки – последствия, которые определяются при установлении соответствия результатов поставки определенным требованиям. Результатом процесса контроля качества являются утвержденные результаты поставки. План управления проектом (обновления). План управления проектом подлежит обновлению в связи с изменениями в плане управления качеством, вызванными результатами процесса контроля качества. Управление качеством / Процессы / Контроль качества / Выходы 41
Заключение 1 n Качество продукта, услуги, процесса, проекта – это соответствие ожиданиям пользователя / целям заинтересованных лиц. n Очень важен процессный подход: цель, входы, ресурсы, выходы, пользователи, формализованность. n Управлять процессами и проектами можно только на основе объективной информации (зарегистрированных измеримых параметров). n Эффективность каждого процесса может быть и должна быть измерена. Управление качеством / Заключение 42
Заключение 1 n Организация должна обладать механизмом выявления проблем и постоянного улучшения. n В проекте должны быть запланированы (установлены, формализованы, пробюджетированы) процессы управления качеством. n Основное развитие в области управления качеством производится организацией ISO через стандарты серии ISO 9000. n Существуют простые инструменты для сбора и анализа информации о процессах. Управление качеством / Заключение 43
CMM: зрелость организаций и процессов CMM SW (Capability Maturity Model for Software) – американский стандарт в области качества ПО. Разработан SEI университета Карнеги-Меллон по заказу Министерства обороны США. Уоттс Хамфри (Watts S. Humphrey, 1927 -2010) “Отец качества ПО” 1989 44
CMM В середине 1970 -х годов Министерство обороны США столкнулось с рядом проблем, связанных с разработкой ПО: q Рост сложности задач, стимулируемый развитием аппаратной базы. Появление и широкое внедрение интегральных схем существенно повысило производительность вычислительной техники, что позволило переходить к решению качественно более сложных задач. Рост объема и сложности задач, возлагаемых на программное обеспечение, имел взрывоподобный характер. q Хронические срывы сроков и качества как следствие роста сложности задач. Сроки выполнения проектов постоянно срывались, качество ПО (соответствие ожиданиям заказчика) оставалось на неприемлемо низком уровне, и Министерство обороны США начало всерьез беспокоиться об эффективности расходования бюджетных средств. 45
CMM q Безуспешный поиск методик и инструментов. Усилия были направлены на поиск эффективных методологий и инструментов для разрешения “сугубо технических” (как тогда казалось) проблем программного обеспечения. Почти два десятилетия обещаний поднять производительность и качество работ за счет новых методов и средств разработки ПО ушло на осознание того, что корень зла – не в технике. q Неспособность организаций управлять процессом разработки ПО как основная причина сложившейся ситуации. В конце концов, был сделан вывод, что фундаментальная проблема “хронического кризиса ПО” состоит в неспособности организаций управлять технологическим процессом разработки программного обеспечения. 46
CMM Военные приступили к поиску формальных и объективных методов оценки способности организации-разработчика произвести ПО требуемой сложности в установленные сроки и с требуемым уровнем качества. SEI получил заказ от Министерства обороны США на проведение исследований в этой области. В 1993 г. вышел отчет SEI: CMM SW (Capability Maturity Model for Software) Модель технологической зрелости организации-разработчика ПО 47
CMM Стандарт быстро получил широкое международное признание. Причины популярности: 1. стандарт предназначен только для разработки ПО; 2. по сравнению с другими стандартами управление качеством для разработки ПО в нем прописаны достаточно подробно и детально. Personal Software Process (PSP) 2005 Team Software Process (TSP) 2006 48
CMM: модель технологической зрелости Зрелые и незрелые организации Следуя идеям TQM, исследователи SEI оценку зрелости организаций решили проводить на основе анализа выполняемых этой организацией процессов по разработке ПО. Предполагалось, что организация является тем более зрелой (более предсказуемой), чем более установленными являются применяемые процессы. Первые исследования организаций с этих позиций показали, что организации находятся на разных уровнях зрелости – была проведена классификация этих уровней, разработаны методы оценки уровня организации и предложены способы повышения уровня зрелости организации. Все это вместе составляет модель технологической зрелости организации, или модель зрелости ее технологических процессов. 49
Модель технологической зрелости – описание стадий эволюции, которые проходят организации-разработчики по мере того, как они: определяют, реализуют, измеряют, контролируют, cовершенствуют процессы создания ПО. Модель помогает выбрать адекватную стратегию усовершенствования процессов, предоставляет методическую основу для определения текущего уровня их совершенства и выявления проблем, критичных для качества разрабатываемого ПО. 50
Модель технологической зрелости Основа модели Ø Process (технология, технологический процесс, процесс) – последовательность шагов (действий), предпринимаемых с заданной целью. Точнее: Производственный процесс – набор операций, методов, практик, используемых разработчиками для создания и сопровождения ПО и связанных с ним продуктов (планов проекта, проектных документов, кодов, сценариев тестирования, руководств пользователя). Ø Process Capability (продуктивность, совершенство технологии/процесса) – диапазон результатов, которые можно ожидать от организации, соблюдающей данный технологический процесс. Это понятие имеет отношение к будущим проектам, но базируется на фактических характеристиках технологии, достигнутых на предыдущих проектах. 51
Модель технологической зрелости Основа модели Ø Process Performance (производительность технологии/процесса) – фактические результаты, достигнутые организацией, соблюдающей данную технологию/процесс. Ассоциируется с уже выполненными проектами. Таким образом, производительность фокусируется на достигаемых результатах, в то время как его продуктивность опирается на ожидаемые результаты. Ø Process Maturity (зрелость технологии) – степень определенности, управляемости, наблюдаемости, контролируемости и эффективности процесса, технологии. Фактически, это индикатор полноты технологии и степени последовательности (настойчивости) организации в ее применении на всех проектах. Зрелость определяет потенциал дальнейшего роста совершенства технологии/процесса. 52
Модель технологической зрелости Модель не содержит никаких финансово-экономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем. 53
Уровни зрелости Способность организации качественно выполнять работу была названа зрелостью. За основу при ее оценке создатели модели взяли процессы организации. Дальше они сделали несколько нетривиальных предположений, которые впоследствии были приняты и признаны справедливыми многими ИТ-специалистами (а может быть, и большинством из них). Предположение 1. Существуют качественно отличающиеся уровни зрелости проектной организации, разрабатывающей информационные системы (в модели СММ таких уровней пять). Предположение 2. Всякая организация-разработчик заинтересована в переходе на более высокий уровень зрелости (не только для того, чтобы повысить свои шансы в борьбе за контракты Министерства обороны, но и в целях собственного совершенствования). 54
Уровни зрелости Предположение 3. Переход возможен только на следующий по порядку уровень. “Перескочить” через уровень нельзя (точнее, можно, но риски для организации при этом резко возрастают). Уровни образуют “лесенку”, по которой поднимается организация по мере собственного развития. Каждый уровень характеризуется определенными составом и свойствами процессов организации. 55
Уровни зрелости В модели СММ определены пять уровней технологической зрелости, по которым: § заказчики могут оценивать потенциальных поставщиков (претендентов на получение контракта), § поставщики могут совершенствовать процессы создания ПО. Каждому из уровней технологической зрелости внутри модели СММ дано краткое определение. 56
Пять уровней зрелости 1. Начальный (Initial). Технология разработки ПО в целом характеризуется как импровизированная, применимая только к конкретному проекту, а в некоторых случаях – даже как хаотическая. Лишь некоторые процессы определены, успех всецело зависит от усилий отдельных сотрудников. 2. Повторяемый (Repeatable). Установлены базовые процессы управления проектом ПО, позволяющие отслеживать затраты, следить за графиком работ и функциональностью выходного продукта. Установлена дисциплина процессов, необходимая для повторения успеха предыдущих проектов в той же прикладной области. 57
Пять уровней зрелости 3. Определенный (Defined). Производственный процесс документирован и стандартизован как для управленческих работ, так и для проектирования. Он интегрирован в стандартный производственный процесс организации. Каждый проект использует утвержденную, адаптированную к особенностям данного проекта, версию стандартного производственного процесса организации. 4. Управляемый (Managed). Собираются и накапливаются детальные метрики (объективные количественные данные) качества исполнения процессов и создаваемого продукта. Как производственный процесс, так и продукты оцениваются и контролируются с количественной точки зрения. 58
Пять уровней зрелости 5. Оптимизируемый (Optimized). Постоянное совершенствование процесса создания ПО достигается благодаря количественной обратной связи с процессом и реализации в нем передовых идей и технологий. 59
Модель зрелости должна дать ответ на два вопроса: v На каком уровне зрелости находится организация? v Что надо делать, чтобы перейти на следующий уровень? Модель зрелости CMM является гибкой – она не содержит четких и конкретных (формализованных) указаний на этот счет, а дает некоторую схему поиска ответов на поставленные вопросы и рекомендации по ее использованию. По мнению разработчиков, это расширяет применимость модели. 60
Модель зрелости: схема 61
Модель зрелости: элементы Группы ключевых процессов. Каждый уровень зрелости содержит описание группы ключевых процессов, которые должны выполняться на этом уровне. 62
Модель зрелости: элементы В CMM существуют отдельные работы, называемые ключевыми практиками. Они связаны друг с другом по входам-выходам и служат исходным материалом для построения процессов. CMM не дает указаний относительно способа построения процессов, т. е. связывания ключевых практик в логические последовательности. Наборы ключевых практик называются группами ключевых процессов. “Каждая группа ключевых процессов определяет блок связанных работ, в результате выполнения которых достигается совокупность целей, значимых для повышения продуктивности производственного процесса. Например, для группы ключевых процессов "Управление требованиями" цель состоит в том, чтобы согласовать требования, выдвигаемые к проекту разработки ПО заказчиком и разработчиком”. Группы ключевых процессов 63
Модель зрелости: элементы Группы ключевых процессов, распределенные по уровням зрелости 64
Модель зрелости: элементы Цели. Для каждой группы ключевых процессов определены цели, которые нужно достигнуть для перехода на следующий уровень. Цели достигаются за счет выполнения ключевых практик. В CMM достижение цели означает, что после выполнения ключевых практик получается нужный результат, и он получается стабильно. Способ достижения целей группы ключевых процессов может различаться от проекта к проекту в зависимости от различий в предметной области или среде. Если эти цели на постоянной основе реализуются для всех проектов, то это означает, что организация достигла того уровня зрелости производственного процесса, которому соотнесена данная группа ключевых процессов. Цели 65
Модель зрелости: элементы Разделы Описания ключевых процессов организованы по разделам. Их на каждом уровне пять. Они представляют собой свойства групп ключевых процессов, которые должны быть реализованы на соответствующем уровне. Эти свойства описывают, как процессы реализованы и насколько они легализованы в организации, т. е. официально утверждены и согласованы с корпоративными процедурами, политиками, другими процессами. 66
Модель зрелости: элементы 1. Обязательства по выполнению. Описывают действия, которые должна выполнить организация, чтобы обеспечить установление и стабильность процесса. Обычно касаются установления организационных политик и поддержки со стороны высшего руководства. 2. Необходимые предпосылки Описывают предварительные условия, которые должны выполняться в проекте или организации для компетентного внедрения производственного процесса; обычно касаются ресурсов, организационных структур и требуемого обучения. Разделы 67
Модель зрелости: элементы 3. Выполняемые операции В разделе описаны содержательные работы, которые должны выполняться на данном уровне. Выполняемые операции обычно включают в себя создание планов и реализацию конкретных операций, выполнение и отслеживание работ, а также, по мере необходимости, выполнение корректирующих действий. 4. Измерения и анализ Раздел описывает, что необходимо сделать для измерения процесса и анализа результатов измерений. В этом разделе обычно приводятся примеры измерений, с помощью которых можно определить статус и эффективность выполняемых операций. Разделы 68
Модель зрелости: элементы 5. Проверка внедрения В разделе описываются шаги, позволяющие убедиться в том, что операции выполняются в соответствии с установленным процессом. В раздел обычно входят проверки и аудиты со стороны руководства и работы по обеспечению качества ПО. Разделы 69
Модель зрелости: элементы Ключевые практики. Описание каждого раздела ключевых процессов выражается ключевыми практиками и подпрактиками, выполнение которых способствует достижению целей группы ключевых процессов. Ключевые практики 70
Модель зрелости: элементы Фактически “ключевая практика” – это общее название “действий”, “работ”, “условий, которые должны выполняться”, “шагов”, “операций” и т. д. “Каждая группа ключевых процессов выражается ключевыми практиками, выполнение которых способствует достижению целей группы. Ключевые практики описывают инфраструктуру и операции, которые дают наибольший вклад в эффективное внедрение и установление группы ключевых процессов. Каждая ключевая практика состоит из одного предложения, часто раскрываемого более подробным описанием, в которое могут входить примеры и уточнения. Ключевые практики, иногда называемые ключевыми практиками верхнего уровня, устанавливают основные политики, процедуры и операции для группы ключевых процессов. Компоненты подробного описания часто называются субпрактиками”. Ключевые практики 71
Модель зрелости: элементы Ключевые практики описывают, что необходимо сделать, но их не следует воспринимать в виде догм, устанавливающих, как нужно достигать целей. Вообще говоря, цели группы ключевых процессов могут быть реализованы с помощью альтернативных практик. Интерпретация ключевых практик должна быть разумной, допускающей достижение целей группы ключевых процессов эффективным способом, хотя, возможно, формально и отличающимся от рекомендованного CMM. Ключевые практики 72
Модель зрелости: элементы Взгляд на деятельность по управлению ИТ, при котором вместо процессов рассматриваются их составляющие – ключевые практики, а процессы присутствуют только виртуально, как что-то, что может быть построено из ключевых практик, выглядит на первый взгляд несколько экзотично! До сих пор задача совершенствования управления ИТ решалась внедрением готовых процессов из эталонной процессной модели. Теперь же возникает множество уровней, содержащих разрозненные (т. е. не объединенные в процессы) ключевые практики, и рекомендуемая последовательность продвижения по уровням. Управление ИТ, согласно CMM, совершенствуется по мере продвижения на более высокий уровень зрелости. Ключевые практики 73
Критерии оценки уровня зрелости CMM предлагает следующие критерии оценки соответствия организации тому или иному уровню зрелости: · Целевые установки группы ключевых процессов считаются удовлетворенными, если действующая в организации практика соответствует всем ключевым элементам практики СММ для данной области. · Группа ключевых процессов считается удовлетворяющей соответствующему уровню, если все целевые установки СММ в данной области удовлетворены и не удовлетворяющей, если полностью не удовлетворена хотя бы одна ее целевая установка. · Организация считается соответствующей уровню зрелости, если все ключевые области процессов этого и всех нижестоящих уровней удовлетворены и не считается соответствующей, если хотя бы одна ключевая область процессов этого или любого нижестоящего уровня не удовлетворяет СММ. 74
Принципы CMM: резюме · Зрелость организации есть возможность выполнять сложные проекты. · Зрелость организации определяется через зрелость ее технологических процессов. · Можно выделить уровни зрелости организаций (процессов). В CMM их пять. 75
Принципы CMM: резюме · Модель зрелости – описание способа оценки уровня зрелости и путей перехода на следующий уровень. Модель зрелости описывается: – ключевыми процессами, которые должны выполняться на каждом уровне зрелости; –– каждый ключевой процесс описывается целями и набором разделов – атрибутов, определяющих различные аспекты выполнения процесса; ––– каждый атрибут описывается в виде ключевых практик – отдельных действий и условий, которые должны выполняться. 76
Принципы CMM: резюме · Достижение уровня зрелости определяется по критерию: – уровень достигнут, если удовлетворены все ключевые процессы этого уровня; – ключевой процесс удовлетворен, если достигнуты все его цели; – цели процесса достигнуты, если выполняются все ключевые практики всех разделов или их аналоги. 77
СПАСИБО ЗА ВНИМАНИЕ! 78