Чтобы ваш продукт не уступал продуктам конкурентов, он должен быть дешевле и качественнее, а сама разработка должна осуществляться быстрее. Для эффективной разработки программного обеспечения в модель процесса вводятся механизмы, позволяющие систематически улучшать процесс в соответствии с целями компании. Модель процесса разработки CMMI (Capability Maturity Model Integration) и методология «Шесть Сигм» (Six Sigma) используются для улучшения процесса разработки, что в свою очередь помогает быть эффективными в бизнесе, развивать персонал и повышать удовлетворенность заказчика. CMMI и «Шесть Сигм» хорошо зарекомендовали себя в компании Motorola и ряде других компаниях-разработчиках программных продуктов. Значительных улучшений можно достичь и при использовании одного из этих меxанизмов, ну а их интеграция дает дополнительный эффект. Использование первой методологии обеспечивает инструментальную поддержку, способствует повышению эффективности процесса, а также помогает ускорить практическое внедрение улучшения процесса разработки программного обеспечения.

Успешной интеграции двух этих методологий посвящен ряд публикаций [1], но каждая организация, уже имеющая подобный опыт, способна привнести что-то свое. Не стал исключением и Санкт-Петербургский центр разработки программного обеспечения компании Motorola, внедривший модель CMMI в сочетании с Digital Six Sigma (DSS — модификация методологии «Шести Сигм») и осуществляющий DSS-проекты.

Инфраструктура улучшения процессов организации

Отправная точка улучшения процесса разработки программного обеспечения — построение инфраструктуры, позволяющей инициировать, реализовать и отслеживать изменения (рис. 1). Необходимость улучшений процесса определяется бизнес-целями организации: ориентированность на заказчика, финансы, совершенствование производства, обучение и развитие сотрудников. Бизнес-цели измеряются количественно и определяют набор ключевых показателей, по которым отслеживается достижение поставленных целей. Для формирования бизнес-целей и набора ключевых показателей в Центре Motorola применяются система сбалансированных показателей Balanced Scorecard [2] и «Цель–Вопрос–Метрика» (Goal–Question–Metrics, GQM) [3]. Реализация практик CMMI позволяет выстроить инфраструктуру, а «Шесть Сигм» наполняет инфрастуктуру необходимым инструментарием. Их сочетание позволяет добиться лучших результатов по всем приоритетным направлениям организации, отраженным в бизнес-целях [4].

Рис. 1. Инфраструктура улучшения процесса организации

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

Соответствие фаз DMAIC и практик процессных областей CMMI

При внедрении инструментария DMAIC в модель CMMI на уровне организации необходимо понять соответствие фаз DMAIC и процессных областей CMMI. Особого внимания требует процессная область разработки и внедрения инноваций (Organizational Innovation and Deployment, OID), которая является каркасом структуры улучшения процесса организации и связующим звеном для других процессных областей CMMI. Неслучайно именно эта процессная область представлена во всех фазах DMAIC в таблице соответствия. В варианте, приведенном в таблице 1, отражается перечень задач DMAIC, выделяемых в Motorola, и процессных областей CMMI, наиболее значимых с точки зрения интеграции с DMAIC.

Реализация практик процессной области OID связана с систематическим измерением и анализом показателей эффективности процесса (Measurement and Analysis, MA) и выбором решений на основе анализа вариантов (Decision Analysis and Resolution, DAR). Помимо непосредственной связи с OID, практики процессных областей MA и DAR являются, как показано в таблице 1, значимыми в большинстве активностей DMAIC.

Оценка возможностей процесса (Organizational Process Performance, OPP), количественное управление показателями на основе статистических данных (Quantitative Project Management, QPM), выявление причин возникающих проблем и их разрешение (Causal Analysis and Resolution, CAR) вместе с OID образуют процессные области четвертого и пятого уровней модели CMMI и обеспечивают работу инфрастуктуры улучшения процесса организации.

Можно выделить ряд процессных областей, которые используются в проекте разработки программного обеспечения, а также могут рассматриваться как часть процесса внедрения улучшений, например, разработка (Requirements Development, RD) и реализация требований (Requirements Management, RM), планирование (Project Planning, PP) и отслеживание статуса работ (Project Monitoring and Control, PMC), управление рисками (Risk Management, RSKM), разработка технического решения (Technical Solution, TS), верификация (Verification, VER), организация тренингов (Organizational Training, OT).

Практическая реализация инфраструктуры улучшения процесса

Исторически построение процесса разработки в Санкт-Петербургском центре компании Motorola предшествовало внедрению методологии «Шесть Сигм», однако известны и обратные варианты реализации интегрированной модели другими центрами компании.

Как правило, в организации существует группа процесса разработки программного обеспечения (Software Engineering Process Group, SEPG), в задачи которой входит анализ организационных целей; определение необходимых действий по улучшению процесса, направленных на достижение данных целей; создание плана по внедрению улучшений в процесс. На рис. 2 показаны стадии, которые проходит любой поступающий запрос на улучшение процесса. Такой запрос может быть инициирован как любым сотрудником компании, так и представителями группы процесса. Источниками запросов могут быть анализ эффективности процессов, анализ целей по качеству результаты тестирования, результаты обмена опытом с другими компаниями.

Рис. 2. Практическая реализация процессной области OID и DMAIC

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

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

Практическая реализация инфраструктуры улучшения процесса основана на интеграции DMAIC и процессной области OID (рис. 2). А теперь покажем, каким образом соотносятся фазы DMAIC и практики, составляющие основу данной процессной области (Specific Practices, SP).

D — фаза определения

На практике фазы DMAIC тесно пересекаются, и иногда трудно определить момент окончания одной и начало другой. Это приводит к тому, что на фазу D приходится значительный объем работ, связанных с анализом текущей ситуации, определением цели проекта, выявлением потенциальных слабых мест в процессе, определением направления работ с использованием статистических моделей процесса, определением спонсоров, участников DSS-проекта и консультанта по ведению DSS-проекта, определением сроков начала и завершения каждой фазы проекта. Все эти работы формируют основу проектного плана, и полезным здесь может быть согласование содержания DSS-проекта с руководством компании для корректировки стратегических приоритетов, выделения ресурсов и поддержки руководством внедряемых изменений. Определение состава участников проекта также является немаловажным.

Целесообразным является просмотр имеющихся запросов на улучшение, (уже внедренных или только созданных), на предмет выявления «легких решений»(quick wins). «Легкие решения», как правило, требуют незначительных временных и других ресурсов для реализации, обеспечивая при этом значительные улучшения процесса. Примером может служить повторное использование и адаптация готовых решений данным проектом.

M — фаза измерения

Цель проекта должна быть выражена численными показателями, которые и определяются на данной фазе. Если на фазе M численные характеристики цели требуют уточнения, то можно воспользоваться методикой GQM для выявления всех необходимых численных характеристик (метрик) цели проекта. Набор метрических показателей, сформированный с помощью этой методики, необходим и достаточен для отслеживания поставленных целей. GQM состоит из трех шагов:

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

Методика GQM рекомендована, но необязательна, поскольку DMAIC предлагает достаточный набор инструментов для решения данной задачи. GQM вносит дополнительную систематичность в выявление численных характеристик цели, а также предполагает создание плана на сбор показателей и описание характеристик для их сбора. Результаты действий, выполняемых на данной фазе, используются для формирования окончательного решения руководства и группы процесса о запуске проекта; определения списка необходимых индикаторов; измерения текущих значений выбранных параметров для последующего сопоставления с результатами DSS-проекта.

Достаточно часто при выполнении DSS-проекта, направленного на улучшение процесса разработки программного обеспечения, возникает вопрос об определении погрешности в ходе анализа системы измерения. Как правило, при оценке показателей процесса разработки такой анализ выполняется не с позиции определения повторяемости и воспроизводимости, а с позиции адекватности и достоверности занесения характеристик процесса в автоматизированные хранилища данных по трудозатратам, дефектам и т.д.

А — фаза анализа

Инструментарий DSS предоставляет широкий выбор методов и средств для анализа текущих показателей, выявления факторов процесса разработки, влияющих на данные показатели, и средств выбора единственного решения из множества альтернативных. К таким методам и средствам относятся: статистические методы сравнительного анализа (например, t-tests, ANOVA и др.); методики выявления корневых причин возникновения ошибок (например, «Пять почему», «Диаграмма Ишикавы»); методики анализа затрат и выгод в различных вариантах.

Фаза A и предшествующие ей фазы D и M связаны с первыми двумя практиками OID (рис. 2) и полностью отражают их содержание — cбор и анализ предложений по улучшению; определение и анализ способов решений.

I — фаза улучшения

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

Фаза I характеризуется двумя практиками OID — пилотированием решений и выбором решения для последующего внедрения.

C — фаза контроля

Рис. 3. Результаты интеграции CMMI и DSS Данная фаза предполагает создание и реализацию плана внедрения изменений в процесс организации, проведение обучающих мероприятий для организации, а также разработку рекомендаций по ведению DSS-проектов.

Трактовки CMMI и DMAIC при реализации этой фазы могут различаться. Реализация процессной области OID предполагает измерение эффективности изменений в процессе на уровне организации перед принятием окончательного решения. Этот шаг обеспечивает возможность для организации в целом доработать улучшения, которые не требовались при пилотировании отдельными проектами.

Фазе C соответствуют следующие практики OID — планирование внедрения, непосредственно внедрение и отслеживание эффективности результатов.

Помимо отслеживания эффективности DSS-проектов, которое является временным, осуществляется также постоянный мониторинг бизнес-целей и ключевых процессов организации посредством тренд-анализа метрических показателей. Отслеживание эффективности внедрения улучшений процесса разработки является частью данного анализа и реализует практики процессной области OPP. На рис. 3 показано, каким образом два DSS-проекта Центра разработки Motorola, направленные на снижение цены качества и поддержку заданного уровня соответствия требованиям программных продуктов, влияют на бизнес-результаты организации.

Перспективы углубления интеграции

Интерес к развитию направлений интеграции модели CMMI и методологии «Шесть Сигм» сегодня не ослабевает, поскольку он обусловлен естественной общностью этих механизмов улучшения процесса организации и бесспорными преимуществами такой интеграции. Важно отметить, что внедрение практик четвертого и пятого уровней модели CMMI предполагает статистические подходы, на которых базируется методология «Шесть Сигм». Некоторые практические детали соответствующих процессных областей содержатся в [5]. Интерес поддерживается как компаниями, реализующими эти механизмы на практике, так и непосредственно Институтом программной инженерии университета Карнегги-Меллона, разработчиком модели CMMI. Такая двусторонняя заинтересованность позволяет надеяться на дальнейшее развитие и распространение этой идеи.

Литература

  1. Jeannie Sivity, M. Lynn Penn, Erin Harper, Relationships Between CMMI and Six Sigma. Development, CMU/SEI-2005-TN-005. www.sei.cmu.edu/publications/documents/05.reports/05tn005/05tn005.html.
  2. R. Kaplan, D. Nordon, Translating Strategy into Action: The Balanced Scorecard, Harvard School Press, 1996.
  3. Victor Basili, Software Modeling and Measurement: The Goal/Question/Metrics Paradigm. Technical Report, CS-TR-2956, Department of Computer Science, University of Maryland, College Park, MD 20742, September 1992.
  4. Michael West, Real Process Improvement using the CMMI. 2004, CRC Press.
  5. Steve Masters, SEC(R), November 2007, CMMI High Maturity Appraisal Considerations, secr.ru/?pageid=4460&submissionid=4546.

Наталия Матвиенко (Natalia.Matvienko@motorola.com) — ведущий инженер по качеству программных продуктов; Сергей Севастьянов (Sergey.Sevastyanov@motorola.com) — руководитель отдела качествa программных продуктов; Александр Бабкин (Alexander.Babkin@motorola.com) — руководитель группы развития и автоматизации процесса Санкт-Петербургского центра разработки программных продуктов компании Motorola (Санкт-Петербург).

Модель CMMI

Модель CMMI представляет собой свод требований к технологическим процессам разработки, в том числе разработки программного обеспечения. Дает возможность поэтапно наращивать уровень зрелости процессов с целью снижения производственных рисков и повышения эффективности разработки. Модель создана американским Институтом программной инженерии университета Карнегги-Меллона и основывается на опыте ведущих мировых компаний. Модель позволяет совершенствовать процессы как по отдельности, так и на уровне всей организации. Выделяются следующие уровни зрелости процессов в организации.

Уровень 1. Начальный (initial). Формальные процессы не определены и не используются; возможно частичное неупорядоченное исполнение некоторых процессов.

Уровень 2. Управляемый (managed). Организация внедряет базовые процессы управления проектами и требованиями.

Уровень 3. Определенный (defined). Производится стандартизация процессов, применяемых для разработки программного обеспечения, внедряются более сложные инженерные и управленческие процессы.

Уровень 4. Управляемый численно (quantitatively managed). Внедрение процессов управления проектами и процессами осуществляется на основе численных данных с использованием методик статистического контроля.

Уровень 5. Оптимизирующийся (optimizing). Происходит постоянное совершенствование процессов и технологий разработки в соответствии с бизнес-целями организации.

Методология Six Sigma

«Шесть Сигм», зарегистрированная торговая и сервисная марка компании Motorola, представляет собой структурированный подход к улучшению показателей бизнеса, а также инструментарий с набором статистических и нестатистических методов (John Matthews, Six Sigma: how it works in Motorola. goliath.ecnext.com/coms2/summary_0199-5683512_ITM). Используется для разработки новых процессов, продуктов и услуг (инструментарий DMADV); удешевления и автоматизации процессов (инструментарий DMADDD); улучшения существующих процессов, продуктов и услуг (инструментарий DMAIC).

В Санкт-Петербургском центре разработки программного обеспечения компании Motorola наибольшее распространение получил инструментарий DMAIC: Define (определение направления оптимизации, постановка задачи); Measure (измерение текущих или желаемых показателей); Analyze (выявление корневых причин проблем); Improve (улучшение процесса и пилотирование изменений); Control (внедрение изменений и отслеживание их эффективности).

Digital Six Sigma — модифицированный вариант «Шести Сигм», ориентированный на использование информационных технологий в дополнение к статистическому и нестатистическому инструментарию.

Центр разработки программного обеспечения компании Motorola

Санкт-Петербургский центр разработки программных продуктов Motorola был открыт в 1997 году для выполнения работ по четырем основным направлениям: Java-технологии; программное обеспечение для телекоммуникаций; решения и средства удаленного доступа; мультимедийные решения и технологии. С 1999 года Центр занимается сертификацией процесса разработки программного обеспечения на соответствие мировым стандартам. С 2003 года Центр ведет DSS-проекты, направленные на улучшение процесса разработки. В данной области Центром был достигнут наивысший, пятый уровень по модели SEI-CMM в 2001 году (первым в регионе EMEA), по модели SEI-CMMI — в 2004 году. Также осуществляется сертификация сотрудников по общепризнанной системе сертификации Six Sigma Green и Black Belts.

Инструментарий

В 2003 году компания Motorola осуществила переход на методологию Digital Six Sigma, сделав ставку на внедрение информационных технологий во все сферы бизнеса, в том числе в тренинги, процессы, инструментарии, мониторинг процессов и метрик. На данный момент из наиболее крупных используемых инструментальных средств можно выделить электронную систему SigmaTrack, позволяющую вести документооборот, планирование и отслеживание DSS-проектов по всей организации. SigmaTrack обеспечивает обмен информацией между участниками проектов, позволяя его руководителям отслеживать результаты по текущим и завершившимся проектам.

Статистический инструментарий DSS в Motorola представлен пакетом Minitab одноименной компании, включающим широкий набор методов статистического анализа. Также здесь могут использоваться и другие программные продукты, например JMP от SAS Institute или Statistica от StatSoft.

В качестве нестатистических инструментальных средств используются: набор шаблонов и рекомендаций на основе Microsoft Excel, удобный для выполнения сравнительного анализа данных; средство MindManager от компании Mindjet, позволяющее визуализировать процесс принятия решения, систематизировать информацию, расставлять приоритеты действиям и отслеживать их выполнение.