Ключевые области процесса в модели cmm
Модель CMM (Рис. 21) определяет 5 уровней зрелости, с 1-го по 5-й; по мере подъема по этим уровнем повышается зрелость процесса разработки и он становится все более предсказуемым. На каждом уровне, начиная со 2-го, определяется ряд «ключевых областей процесса» (Key Process Area – KPA), представляющих собой группы взаимосвязанных деятельностей, необходимых для выполнения разработки на данном уровне зрелости, причем каждый последующий уровень включает в себя все ключевые области процесса предыдущего уровня – строится на его базе. Важно не только исполнять указанные деятельности, но исполнять их с высокой оценкой соответствия поставленным целям и другим атрибутам данной ключевой области процесса.
Всего модель CMM определяет 18 ключевых областей процесса. Для каждой из этих ключевых областей модель CMM называет деятельности, которые должны исполняться (от 3 до 5), формулирует их цели (от 2 до 4) и конкретизирует, в чем именно должны проявляться желание исполнить и возможность исполнить данную ключевую область процесса.
Модель CMM не формулирует, как именно должна выполняться та или иная определенная в модели деятельность; она только называет эти деятельности, оставляя порядок и методику их исполнения на усмотрение разработчиков. Единственное, что требуется – это наличие подтверждающих документов (evidences), свидетельствующих о совершении данной деятельности и позволяющих судить о качестве ее исполнения в свете сформулированных в модели целей для ключевой области процесса, к которой данная деятельность относится.
Первый уровень зрелости называется начальным (initial), потому что не предполагает никаких знаний о процессе разработки; все деятельности в нем выполняются ad hoc (как придется, для данного случая), поэтому на этом уровне отсутствует какая-либо предсказуемость результата разработки. Это не значит, что на первом уровне не бывает удачных проектов, однако сказать что-либо определенное о продукте можно только по завершении разработки (если только она будет завершена).
Рис. 21. Уровни и ключевые области процесса в модели CMM
Второй уровень зрелости называется повторяемым (repeatable), потому что процесс этого уровня обеспечивает возможность относительно легкого воспроизведения процесса разработки для нового продукта с теми же, что и ранее, результатами при относительно сходных начальных условиях. Ключевых областей на этом уровне шесть.
(1). Управление требованиями (Requirements Management). Основной целью данной ключевой области является обеспечение возможности установления единого с заказчиком понимания требований к разрабатываемому программному продукту. Именно этот этап является наиболее сложным, поскольку заказчик в начале работы над проектом часто имеет только более или менее определенные пожелания, что должно делать проектируемое программное изделие. Кроме того, в процессе выполнения проекта изменяются представления о самом продукте и у заказчика, и у разработчика. Поэтому в ключевой области «Управление требованиями» предусмотрена работа с требованиями заказчика по исключению из них неопределенностей и неоднозначностей и преобразованию исходных требований в более или менее формализованную спецификацию требований. Это дает возможность составлять такую спецификацию требований, в которой установлено однозначное определение всех деталей, касающихся будущего продукта, и определены эффективные методы его тестирования.
(2) Планирование проекта (Software Project Planning). Цель данной ключевой области заключается в создании условий для составления реально выполнимого проектного плана и реального графика выполнения проекта и собственно разработка этих документов. Результатом деятельностей в этой ключевой области является проектный план и график его выполнения. Под проектным планом понимается один план или совокупность связанных планов по реализации различных компонентов проекта в соответствии с процессом. В этой ключевой области осуществляется некоторая совокупность деятельностей, связанных с разработкой установленного набора согласованных планов, которые в дальнейшем постоянно используются как средство отслеживания хода разработки продукта и управления программным проектом.
(3) Отслеживание проекта (Software Project Tracking and Oversight). Цель данной ключевой области – установление верной отображаемости хода выполнения проекта, которая должна быть организована так, чтобы обеспечивалась возможность наглядного обнаружения отклонений от планов на ранней стадии их возникновения и имелась наглядная картина хода выполнения проекта. Такая организация отображаемости проекта придает руководителям всех уровней потенциал своевременного принятия корректирующих действий для предотвращения возможных надвигающихся проблем.
(4) Управление субподрядчиками (Subcontractor Management). Целью данной ключевой области является определение правил выбора подрядчиков и субподрядчиков для выполнения тех видов работ по разработке программного продукта, которые по разным причинам нецелесообразно выполнять внутри организации-исполнителя. Организация-исполнитель в этом случае обеспечивает эффективное управление своими субподрядчиками, координирует их деятельности по разработке программного продукта и включению получаемых рабочих продуктов в состав создаваемого программного продукта и несет полную ответственность перед заказчиком за соблюдение всех условий и требований к разработке и конечному продукту.
Эта область имеет в себе элементы всех ключевых областей второго уровня зрелости. Однако деятельности в этой области могут отсутствовать в стандартном процессе предприятия, если программный проект выполняется целиком силами данного предприятия и внутри него.
(5) Обеспечение качества (Software Quality Assurance). Цель данной ключевой области – создание условий для поддержания надлежащего качества разработки и поставляемого продукта. Деятельности в этой ключевой области обеспечивают требуемые эффективность процесса и качество выпускаемого продукта и осуществляются в соответствии со специальным планом по обеспечению качества, в котором эти деятельности должны быть определены и взаимоувязаны с остальными рабочими планами.
(6) Управление конфигурацией (Software Configuration Management). Цель данной ключевой области заключается в обеспечении единой системы идентификации компонентов программного продукта, включая среду его разработки, контроля над изменениями и управления изменениями этих компонентов и обеспечении целостности всего продукта. Эти деятельности должны выполняться на протяжении всего жизненного цикла разработки. Как и в случае обеспечения качества, управление конфигурацией осуществляется по специальному плану, в котором взаимоувязан весь предусмотренный для этого перечень деятельности.
Третий уровень зрелости называется определенным (defined), потому что для процесса этого уровня каждая деятельность определена в книге процесса предприятия, и все участники проекта обязаны строго следовать ее предписаниям. К предыдущим шести ключевым областям добавляются еще семь:
(7) Нацеленность процесса (Organization Process Focus). Цель ключевой области заключается в выделении набора компонентов конкретной реализации процесса, который обусловил бы требуемые способности данного предприятия по разработке программных продуктов. Результатом является выделение некоторого набора компонентов процесса для его дальнейшего определения. Кроме того, в этой ключевой области явно формулируются цели, ради которых процесс третьего уровня вводится. При этом для всех сотрудников предприятия должно быть обеспечено ясное понимание всех преимуществ, которые будут достигнуты в результате успешной аттестации предприятия на заданный уровень зрелости.
(8) Определение процесса (Organization Process Definition). Цель – окончательное определение каждого компонента конкретной реализации процесса из набора компонентов, выделенных в ключевой области “Нацеленность процесс”, так, чтобы обеспечивалась эффективность процесса по всем проектам, выполняемым на предприятии. В результате происходит определение стандартного процесса данного предприятия. Основным итогом является перечень технологических и организационных деятельностей, набор механизмов, формальных процедур и стандартов, которые должны быть описаны в книге процесса таким образом, чтобы обеспечивалась их однозначное понимание. Определенный таким образом стандартный процесс подлежит внедрению на предприятии и последующему систематическому совершенствованию.
(9) Программа обучения (Training Program). Цель данной ключевой области – создания необходимых условий для развития навыков и знаний у исполнителей проектов для более эффективного выполнения поставленных перед ними задач. Непрерывное плановое повышение квалификации является важным элементом организационной дисциплины. В каждом проекте отдельно должно быть определено, какие навыки, в каком объеме и для каких деятельностей нужны данному проекту, должно быть обеспечено необходимое обучение в соответствии с выявленными пробелами в знаниях. На предприятии должна быть постоянно действующая эффективная в смысле минимизации затрат при получении заданной выгоды программа повышения квалификации, должны быть соответствующие этой программе планы, организационное и ресурсное обеспечение.
(10) Интегрированное управление (Integrated Software Management). Цель этой ключевой области состоит в том, чтобы обеспечить соединение всех технологических и организационных процессов, протекающие на предприятии (технический процесс разработки ПИ, процесс управления проектом, процесс управления предприятием в целом и другие процессы) в единый согласованный и эффективный (интегрированный) процесс управления. Первоначально интегрированный процесс должен строиться исходя из тех компонентов стандартного процесса, которые определены для третьего уровня зрелости. В дальнейшем он должен совершенствоваться и включать в себя компоненты процессов более высоких уровней зрелости. Из стандартного интегрированного процесса путем подгонки создается проектный процесс, наилучшим образом приспособленный для выполнения конкретного проекта.
(11) Технология разработки продукта (Software Product Engineering). Цель данной ключевой области – определение технологического процесса разработки программного продукта. Технологический процесс предприятия должен задавать всю технологическую деятельность по результативной разработке качественных программных продуктов от начала и до конца. Он должен включать стандарты и описания всех технических видов деятельности, таких как анализ и составление требований, высокоуровневое и детальное проектирование, кодирование и отладка, системное тестирование и т.п. Определенный таким образом технологический процесс обязателен к соблюдению в каждом проекта. Если для какого-либо проекта необходима так называемая «подгонка» стандартного процесса предприятия (process tailoring), то она осуществляется в соответствии с принятой процедурой и документированием всех отклонений от стандартного процесса с обязательным обоснованием всех отклонений.
(12) Межгрупповая координация (Intergroup Coordination). Цель этой ключевой области заключается в обеспечении условий для активного повторного использования знаний, продуктов и технологических приемов, накопленных на предприятии отдельными группами исполнителей при выполнении разных проектов. Активизация повторного использования достигается путем деятельного взаимодействия отдельных групп исполнителей друг с другом. Взаимодействие между всеми группами разработчиков исполняется в соответствии с планом, координируется и управляется. Обычные формы межгупповой координации – общие семинары, операционные обзоры и научно-практические конференции сотрудников, часто с участием заказчиков и приглашенных лиц.
(13) Товарищеские обзоры (Peer Reviews). Цель ключевой области – обеспечение условий для раннего обнаружения и наиболее действенного устранения ошибок и дефектов, обнаруженных в продуктах проекта. Важным результатом деятельностей в этой ключевой области является выявление и анализ причин, вызвавших дефекты, выработка эффективных мероприятий по предотвращению выявленных причин в будущем. Обзоры с коллегами – это важный и эффективный технологический прием, который является компонентом технологического процесса разработки программного продукта. Обязательному товарищескому обзору подлежат низкоуровневый проект и программный код, но желательно, чтобы такой обзор проходили, как минимум, все поставки заказчику.
Четвертый уровень зрелости получил название управляемый (managed), потому что процесс этого уровня обеспечивает возможность реального управления производительностью, длительностью жизненного цикла разработки и качеством выпускаемого программного продукта на основе постоянных измерений и анализа различных метрик, характеризующих процесс разработки и создаваемые в нем рабочие продукты. На этом уровне к 13 ключевым областям двух предыдущих уровней добавляются еще две.
(14) Количественное управление процессом (Quantitative Process Management). Цель этой ключевой области состоит в том, чтобы обеспечить возможность управления эффективностью стандартного процесса по реальным и объективно измеряемым данным. Как и любая деятельность в СММ, претворение в жизнь количественного управления процессом является плановой. В таком плане определяются все действия по улучшению процесса, ставятся достижимые цели по его эффективности и устанавливается регулярность измерения и анализа метрик процесса. Суть количественного управления процессом в том, что сначала определяются реальные отклонения текущих значений метрик процесса от целевых значений и выявляются причины, вызвавшие эти отклонения. Далее проводится анализа выявленных причин. На основе результатов анализа вырабатываются требуемые управляющие воздействия для улучшения процесса, и планируется их исполнение.
(15) Управление качеством (Software Quality Management). Целью этой ключевой области является создание возможности управления достижением целевых количественных показателей по качеству как конечного программного продукта, так и всех промежуточных рабочих продуктов разработки. Для обеспечения этого необходимо составление плана управления качеством, согласованного со всеми остальными планами по проекту, и применение той же метрической программы, что и в ключевой области «Количественное управление процессом». Заметим, что если процесс второго уровня зрелости обеспечивает только достижение установленного уровня качества программного продукта, то процесс четвертого уровня дает возможность управлять повышением или понижением достигнутого уровня качества в целях оптимизации баланса «качество-сроки-бюджет».
Пятый уровень зрелости называется оптимизационным (optimizing), потому что на нем обеспечивается автоматизированная возможность постоянного совершенствования стандартного процесса в смысле повышения его эффективности. На этом уровне к 15 ключевым областям трех предшествующих уровней добавляются заключительные три.
(16) Предотвращение дефектов (Defect Prevention). Цель данной ключевой области – создание условий для результативного выявления и устранения причин возникновения дефектов в прошлом для предотвращения возможности возникновения дефектов того же типа в будущем. Деятельности в этой ключевой области осуществляются также в соответствии с планом, в котором устанавливаются правила проведения анализа дефектов и выявления причин их возникновения. По результатам анализа вырабатывается и планируется к исполнению совокупность мероприятий и действий для исключения причин, вызывающих возникновение дефектов выявленных типов. В результате деятельностей в этой ключевой области должны быть созданы условия, при которых дефекты известных типов не могли бы возникать вообще.
(17) Управление изменениями технологии (Technology Change Management). Цель этой ключевой области заключается в обеспечении установленного порядка в определении эффективности применения передовых технологий и возможности управления внедрением новых. Внедрение новых технологий является плановым мероприятием. План внедрения новых технологий должен быть взаимоувязан со всеми планами, имеющимися в проекте и в организации в целом. Внедрению новых технологий придается особое значение, поскольку добиться лучших результатов невозможно, не используя в процессе разработки новые, более эффективные технологии. При внедрении новых технологий должно отслеживаться соотношение преимуществ от их применения с понесенными затратами на их внедрение. Величина этого соотношения должна играть определяющую роль при принятии решения о внедрении новой технологии, причем оценка этого соотношения сначала осуществляется в одной или нескольких проектных группах. При получении положительных результатов от пилотных внедрений и проведения их анализа, новые технологии внедряются по всему предприятию.
(18) Управление изменениями процесса (Process Change Management). Цель этой последней ключевой области состоит в обеспечении возможности систематического выявления характеристик процесса, требующих улучшения, и автоматизированном управлении улучшением этих характеристик. Для управления изменениями процесса также необходимо иметь план, который должен быть согласован с планами по предотвращению дефектов, внедрению новых технологий, планом разработки программного продукта и другими планами. Все деятельности в этой ключевой области осуществляются в соответствии с порядком, описанным в книге процесса.