Модель зрелости конструирования программных систем смм. Capability Maturity Model (Модель развития функциональных возможностей) (CMM)

Эволюцию моделей обеспечения качества рассмотрим на основе "модели зрелости процесса", или "модели совершенствования возможностей" СММ (Capability Maturity Model). Несмотря на то что модель СММ направлена на обеспечение качества программного обеспечения, ее методологические аспекты применимы к моделям обеспечения качества любой продукции (товаров, работ, услуг).

Главным в модели СММ является понятие зрелости организации.

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

Зрелой считается организация, в которой выполняются следующие условия:

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

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

Рис. 5.3. Пять уровней зрелости модели СММ

Начальный уровень (initial level) является основой для развития предприятия на следующих уровнях. Считается, что на предприятии начального уровня организации не существует стабильных условий для создания качественного программного обеспечения. Следовательно, результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов. Это означает, что успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Если же получившие в проектах опыт менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимого программного обеспечения.

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

Достижение второго, повторяемого уровня (repeatable level ) определяется внедрением на предприятии технологии управления проектами. Планирование и управление проектами на предприятии основывается на накопленном опыте, существуют и используются стандарты на разрабатываемое программное обеспечение, соблюдение которых контролируется специальной группой обеспечения качества. Считается, что второй уровень может как обеспечить возможности для дальнейшего совершенствования (перехода на третий уровень), так и не исключает вероятность в критических условиях регрессивного возврата качества процесса создания программного обеспечения на начальный уровень.

Третий, определенный уровень (defined levet) характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения полностью задокументирован, начиная от разработки программного обеспечения и заканчивая управлением проектами. Гипотеза внедрения этого уровня состоит в том, что в процессе стандартизации происходит переход предприятия на наиболее эффективные практики и технологии. Для создания и поддержания функционирования стандартов разработки программного обеспечения и управления проектами в организации должна быть создана специальная группа. Обязательным условием для достижения третьего уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Считается, что начиная с этого уровня организация перестает зависеть от качеств конкретных разработчиков и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.

На четвертом, управляемом уровне (managed level) на предприятии устанавливаются количественные показатели качества – как на программные продукты, так и на процессы их создания в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных проектных показателей. При этом разделяются осмысленные (сигнальные) вариации реализуемых процессов создания программного обеспечения и случайные (шумовые) вариации процесса.

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

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

Как правило, менеджмент качества программных проектов основывается на знаниях из трех источников:

Программный инжиниринг (ACM, IEEE);

Менеджмент проекта (PMI);

Качество (ASQ).

Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон объединяет все эти три источника.

Модель зрелости функциональных возможностей (Capability Maturity Model, СММ) , служит "каркасом" процесса разработки ПО. Эта модель основана на практических действиях, и отображает лучшие результаты индивидов, работающих над усовершенствованием процесса разработки ПО и выполняющих оценочный анализ этого процесса. В дальнейшем мы будем ссылаться на то, каким образом менеджмент качества программных проектов соответствует модели СММ SEI. Поскольку модель СММ хорошо известна в сообществах разработчиков ПО, нет особой потребности приводить ее определение. Мы представим лишь краткое ее описание, чтобы продемонстрировать необходимость использования жизненного цикла в процессе разработки. Ниже приведена краткая обобщенная характеристика уровней развития функциональных возможностей модели СММ.

Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки. Говоря об уровне развития функциональных возможностей, обычно подразумевают строго определенную стадию развития, направленного на получение законченного процесса разработки ПО. При разделении модели СММ на пять уровней, первостепенное внимание уделяется направленным на усовершенствование действиям, необходимым для завершения работы над развитием функциональных возможностей процесса. Эти пять уровней можно кратко описать, присвоив им следующие характеристики.

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

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

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

Управляемый. Собираются детальные показатели процесса разработки ПО и качественные характеристики продукта. Управление процессом разработки программных продуктов осуществляется на количественном уровне.

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

Эта связь достигается при осуществлении самого процесса, а также на базе новаторских идей и технологий. Каждый уровень зрелости разбивается на несколько ключевых областей процесса, указывающих на то, какие действия еще необходимо предпринять для усовершенствования процесса разработки ПО. Каждая ключевая область процесса (Key process area, KPA ) определяет набор взаимосвязанных действий, необходимых для оптимизации этого процесса.

Области КРА на уровне 2 относятся к возникающим при выполнении программного проекта вопросам, которые связаны с созданием базовых средств управления менеджментом проекта. На данном этапе обсуждения нам необходимо знать, что повторяющийся процесс (уровень 2) позволяет оптимизировать структуризацию и управление в организации. При наличии такого определения формируется единый язык, и облегчаются переходные периоды при включении в процесс разработчиков, особенно если у них недостаточно опыта в этой области.

Однако наличие повторяющегося процесса (уровень 2) заведомо не приводит к хорошо разработанному процессу. В общем, усовершенствование процессов происходит тогда, когда организация достигает уровня 3. Уровень 3 относится к решению как связанных с выполнением проекта, так и организационных вопросов, поскольку организация создает инфраструктуру, обеспечивающую эффективный программный инжиниринг и менеджмент по всем проектам. Две области КРА, определение организации процесса и интегрированный программный менеджмент, относятся к предметной области жизненных циклов.

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

Действия, формирующие процесс построения организационной структуры, включают документирование и сопровождение описательных характеристик жизненных циклов разработки ПО. Цель интегрированного программного менеджмента области КРА на уровне 3 заключается в том, чтобы объединить программный инжиниринг и управленческую деятельность в логически последовательный определенный процесс разработки ПО, полученный в результате адаптации стандартного процесса разработки ПО в данной организации и связанных с ним ценных свойств процесса, описанных в "Определении процесса на уровне его структуры".

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

Организации, применяющие эту модель в качестве механизма измерения и совершенствования процессов, должны использовать приемлемую интерпретацию областей знаний процесса в аспекте деловых целей. При использовании этой модели в качестве средства оценки процессов и инструмента измерения, она становится своего рода "дорожной картой", обеспечивающей успешное улучшение процесса. Вообще говоря, модель СММ можно рассматривать в качестве совокупности четко сформулированных концепций инжиниринга и менеджмента, основанных на проверенных принципах обеспечения. В процессе разработки ПО, когда знания требуется должным образом оценивать и защищать, следует уделять немалое внимание принципам обеспечения качества. Модель СММ не является сборником предписаний на все случаи жизни. Здесь не указывается, каким образом организация должна устанавливать атрибуты процесса. Также ее применение не гарантирует немедленный успех. Процесс внедрения улучшений требует времени и непрерывных усилий в масштабах всей организации. При этом особое значение приобретает исполнительный менеджмент и выделенные средства. Модель СММ трудно отнести к разряду универсальных методологий, когда "один размер пригоден на все случаи жизни". Первый шаг, который требуется сделать на пути использования этой модели, заключается в настройке приложений уровней зрелости в соответствии с конкретной организацией и имеющимся набором проектов. Институтом SEI были разработаны другие модели зрелости возможностей, которые применимы к персоналу организации, процессу приобретения ПО, инжинирингу систем, интегрированному процессу разработки программного продукта, а также по отношению к персональному программному процессу.

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

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

Определенный - указывается "способ, требуемый для выполнения дела";

Документированный - разработан таким образом, что может быть известным и используемым в дальнейшем;

Изученный - обучение на основе документации;

Практичный - может применяться на практике, а не откладываться в "долгий ящик";

Поддерживаемый - доступный, пересмотренный и улучшенный;

Контролируемый - изменения одобрены "участниками совместного дела";

Верифицирован - процесс выполняется корректно;

Проверен - выполняется именно тот процесс, который необходим;

Измеренный - оцененная производительность применяется в качестве базиса для контроля и улучшения процесса;

Способность к улучшению - гибкость и способность к изменениям.

Инжиниринг программных продуктов относится к области ключевых процессов для уровня 3, т.е. "определенного". До 1968 года термин "программный инжиниринг" вообще не применялся. Программный инжиниринг представляет собой практическое приложение научных знаний к процессу проектирования и разработки компьютерных программ. Этот процесс также называется разработкой ПО или производством программ.

Первое появление широко распространенного ПО датируется 1890 годом. Именно в это время в Американских центрах по проведению переписи населения появились перфокарты Германа Холерита (1860-1929 гг.), Массачусетский технологический институт, Кембридж, штат Массачусетс.

В это же время произошел первый перерасход средств по вине "компьютеров". Результаты центров по проведению переписи населения США изначально были протабулированы с помощью вспомогательных механических средств; механических табуляторов Германа Холлерита. В это же время и начало развиваться производство перфокарт. Средства, затраченные на табуляцию данных центров переписи населения, на 98 % превышали аналогичные затраты, понесенные в прошлом. Отчасти это объясняется тем, что шаблон, используемый при табуляции данных, был разработан весьма подробно и объем табулированных данных превышал минимально необходимое количество. Хотя и сам процесс табуляции был значительно ускорен. В это же время появились перфокарты, считывание которых выполнялось электрическим способом.

Возвращаясь к модели СММ, отметим, что на уровне 2 процесс разработки ПО можно представить в виде набора "черных ящиков" с определенными контрольными точками (стадиями). Как показано на рис. 2.1, требования включаются в состав процесса и плавно "перетекают" в набор из "черных ящиков".

Рис. 2.1. Процесс уровня 2

Для каждого ящика генерируются результаты вычислений, а стадии и контрольные точки применяются с целью мониторинга процесса разработки программного продукта. Затем следует стадия внедрения политик, стандартов и процедур. Количественная оценка этого опыта производится с помощью элементарной метрической системы, применяемой в данном проекте. Контроль производится посредством применения формальных практик, задействованных в процессе менеджмента проектов. Также отслеживаются затраты, графики и набор функциональных свойств. Основными субъектами процесса являются требования к ПО и рабочие продукты, а их целостность контролируется с помощью системы менеджмента конфигурации. Для проектов характерны тесные взаимосвязи со службой поддержки заказчиков. Также вырабатывается способность к осуществлению программных процессов.

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

Рис. 2.2. Процесс уровня 3

В рамках проектов происходит подгонка стандартных программных процессов организации для их конкретизации. Также интегрируются процессы менеджмента и программного инжиниринга. Возможности по выполнению стандартного процесса являются стандартными, а группа разработчиков несет ответственность за действия, выполняемые в программном проекте. Ниже перечислены области КРА для третьего уровня зрелости:

1) область действия организационного процесса;

2) определение организационного процесса;

3) инжиниринг программных продуктов;

4) комплексный менеджмент ПО;

5) взаимодействие между группами;

6) экспертные оценки;

7) учебная программа.

На уровне 3 процесс разработки ПО осуществляется на основе хорошо определенного процесса. Требуется осознание ролей и ответственности в ходе осуществления процесса. Процесс производства программного продукта отображается в ходе выполнения программного процесса.

Уровень 4 (рис. 2.3), т.е. "управляемый", включает две области КРА: количественный менеджмент процессов и управление качеством ПО.

Рис. 2.3. Процесс уровня 4

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

На уровне 5 ("оптимизация") области КРА сосредоточены на стадиях менеджмента изменений технологии, менеджмента изменений процесса и предотвращении дефектов. Благодаря непрерывному улучшению процесса осуществляется количественная обратная связь по отношению к процессу разработки программ. На этом уровне в организации могут апробироваться новые идеи и технологии, позволяющие улучшить качество программного продукта, что схематически изображено на рис. 2.4.

Рис. 2.4. Процесс уровня 5

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

1) процесс должен соответствовать культурным традициям организации;

2) менеджмент обязан способствовать повышению степени культуры;

3) культура должна способствовать внедрению ролевых моделей и наград.

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

В 1982 году Министерство обороны США образовало комиссию, основной задачей которой стало исследование проблем, возникающих при разработке программных продуктов в организациях министерства. В результате деятельности комиссии в декабре 1984 году был создан Институт инженеров-разработчиков программного обеспечения ( Software Engineering Institute, SEI ) на базе Университета Карнеги-Меллона в Питсбурге.

1987 г. SEI публикует: краткое описание структуры CMM ; методы оценки процессов разработки ПО ; методы оценки зрелости процессов производства ПО ; анкету для выявления степени зрелости процессов (для проведения самостоятельного, внутреннего аудита и внешнего аудита).

1991 г. Выпуск версии CMM v1.0.

1992 г. Выпуск версии CMM v1.1.

1997 г. Выпуск очередной (усовершенствованной) версии CMM .

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов. Для этого предполагалось создать критерии оценки зрелости ключевых процессов компании-разработчика и определить набор действий, необходимых для их дальнейшего совершенствования. В итоге методология оказалась чрезвычайно полезной для большинства компаний, стремящихся качественно улучшить существующие процессы проектирования, разработки, тестирования программных средств и свести управление ими к понятным и легко реализуемым алгоритмам и технологиям, описанным в едином стандарте.

СММ де-факто стал именно таким стандартом. Его применение позволяет поставить разработку ПО на промышленную основу, повысить управляемость ключевых процессов и производственную культуру в целом, гарантировать качественную работу и исполнение проектов точно в срок. Основой для создания СММ стало базовое положение о том, что фундаментальная проблема "кризиса" процесса разработки качественного ПО заключается не в отсутствии новых методов и средств разработки, а в неспособности компании организовать технологические процессы и управлять ими.

Для оценки степени готовности предприятия разрабатывать качественный программный продукт СММ вводит ключевое понятие зрелость организации ( Maturity ). Незрелой считается организация, в которой:

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

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

Основные признаки зрелой организации:

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

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

Каждый из уровней, кроме первого, состоит из нескольких ключевых областей процесса (Key Process

Модели совершенствования

Совершенствование процессов работы с требованиями

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

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

Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) . Подъем экономики послевоенной Японии во многом был обусловлен идеям, заложенным в TQM.

Качество - термин, который для одних означает необходимость делать то, что желает потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. .

Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как определить, что работа завершена? Необходимо также продумать, как вы собираетесь управлять данным процессом и как его можно усовершенствовать.

Основные принципы ISO9000:

• Концентрация на потребностях заказчика;
• Активная лидирующая роль руководства;
• Вовлечение исполнителей в процессы совершенствования;
• Реализация процессного подхода;
• Системный подход к управлению;
• Обеспечение непрерывных улучшений;
• Принятие решений на основе фактов;
• Взаимовыгодные отношения с поставщиками.

Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно общий характер и не учитывают специфику предприятий отрасли IT. Для этого были разработаны специализированные подходы, рассмотренные ниже.

Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.

Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации - разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в ). Данный стандарт получил широкую известность, значительное количество западных IT-компаний сертифицировано по CMM.

В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем .

CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) соответствует структуре SW-CMM с небольшими уточнениями наименований уровней. Пять уровней зрелости содержат 22 области технологических процессов, показанных в таблице 14.1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation), содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).

В непрерывном представлении вместо уровней зрелости определяются шесть уровней способностей (capability levels) для каждой области технологических процессов. Это представление позволяет каждой организации решать, какой уровень способностей ей соответствует в каждой из 22 областей технологических процессов.

Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая "Управление требованиями", но, в отличие от предыдущего стандарта, на уровне 3 есть и отдельная область "Разработка требований". Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований .

Область процессов "Управление требованиями"

Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых свойств требований) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования:

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

Область процессов "Разработка требований"

В CMMI-SE/SW описаны три набора приемов разработки требований:

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

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

CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14.1).

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

Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х годов американский Институт программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.

Сегодня на западе компания-разработчик практически испытывает большие трудности с получением заказов, если она не аттестована по СММ. Заказчики требуют гарантий технологичности компании-исполнителя, гарантий того, что исполнитель не может оказать некачественную услугу.

Оценка технологической зрелости компаний может использоваться:

· заказчиком при отборе лучших исполнителей (например, в тендере);

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

· компаниями, решившими пройти аттестацию, для оценки «размеров бедствия», т.е. своего текущего состояния;

· аудиторами для определения стандартной процедуры аттестации и проведения необходимых оценок;

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

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

Зрелость процессов (software process maturity) - это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации. Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения. Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать.

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

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

Начиная с 1990 г. SEI при поддержке правительственных структур США и организаций-разработчиков ПО постоянно развивает и совершенствует эту модель, учитывая все новейшие достижения в области создания и сопровождения ПО.

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

СММ - это описательная модель в том смысле, что она описывает существенные (или ключевые) атрибуты, которые определяют, на каком уровне технологической зрелости находится организация. Это нормативная модель в том смысле, что детальное описание методик устанавливает уровень организации, необходимый для выполнения проектов различной сложности и продолжительности по контрактам с правительственными структурами США. СММ не является предписанием, она не предписывает организации, каким образом развиваться. СММ описывает характеристики организации для каждого из уровней технологической зрелости, не давая каких-либо инструкций как переходить с уровня на уровень. Организации может потребоваться несколько лет для перехода с первого на второй уровень и совсем мало времени для перехода с уровня на уровень далее. Процесс совершенствования технологии создания ПО отражается в стратегических планах организации, ее структуре, используемых технологиях, общей социальной культуре и системе управления.

На каждом уровне устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов. Выход на каждый уровень технологической зрелости является результатом появления определенно­го количества компонентов в процессах создания ПО, что в свою очередь приводит к повышению их производительности и качества. На рис. 1.7 показаны пять уровней технологической зрелости СММ.

Рис. 1.7. Пять уровней технологической зрелости СММ

Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.

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

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

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

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

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

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

Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов (key process areas - КРА). Модель СММ содержит 18 таких групп, последняя версия модели CMMI - 20 групп. Уровень 2 СММ характеризуется наличием в организации следующих процессов (их наименования соответствуют CMMI):

· управление требованиями;

· управление конфигурацией;

· планирование проекта;

· мониторинг и контроль проекта;

· управление контрактами;

· измерения и анализ;

· обеспечение качества процесса и продукта.

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

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

На данном уровне к процессам уровня 2 добавляются следующие процессы:

· спецификация требований;

· интеграция продукта;

· верификация;

· аттестация;

· стандартизация процессов организации;

· обучение;

· интегрированное управление проектом;

· управление рисками;

· анализ и принятие решений.

Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов. На этом уровне в организации создается специальная группа, ответственная за состав операций, из которых состоят процессы, - группа по разработке процессов создания ПО (software engineering process group - SEPG).

На основе единой технологии для каждого проекта могут разрабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные процессы создания ПО» (project"s defined software process).

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

Главное назначение уровня 4 (уровня управляемых процессов) - текущий контроль над процессами. Управление должно обеспечивать выполнение процессов в рамках заданного качества. Могут быть неизбежные потери и временные пики в измеряемых результатах, которые требуют вмешательства, но в целом система должна быть стабильна.

На уровне 4 добавляются следующие процессы:

· управление производительностью и продуктивностью;

· количественное управление проектом.

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

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

Результаты выполнения процессов на четвертом уровне становятся предсказуемы, поскольку они измеряемы и варьируются в рамках заданных количественных ограничений. На этом уровне появляется возможность заранее планировать заданное качество выполнения процессов и конечной продукции.

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

На уровне 5 добавляются следующие процессы:

· внедрение технологических и организационных инноваций;

· причинно-следственный анализ и разрешение проблем. Процессы создания и сопровождения ПО характеризуются

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

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

Каждый последующий уровень дополнительно обеспечивает более полную обозримость самих процессов создания и сопровождения ПО.

На первом уровне процессы являются аморфными («черными ящиками»), и их обозримость весьма ограничена. С самого начала состав и назначение операций практически не определены, что порождает значительные трудности в определении состояния проекта и его продвижения. Требования по выполнению процессов задаются бесконтрольно. Разработка ПО в глазах менеджеров (особенно тех, кто сам не является программистом) иногда выглядит как черная магия.

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

На третьем уровне определена внутренняя структура «черных ящиков», т.е. задачи, из которых состоят процессы. Внутренняя структура представляет собой путь, по которому стандартные процессы в организации применяются в конкретных проектах. Звено управления и исполнители в необходимой степени детализации знают свои роли и ответственность в рамках проекта. Руководство заранее подготовлено к рискам, которые могут возникнуть в процессе выполнения проекта. Так как стандартизированные и документированные процессы становятся «прозрачными» для обозрения, сотрудники, непосредственно не занятые в проекте, могут своевременно получать точные сведения о его текущем состоянии.

На четвертом уровне выполнение процессов жестко привязывается к инструментальным средствам, что дает возможность определения количественных характеристик их трудоемкости и качества выполнения. Руководители, имея объективную базу количественных измерений, получают возможность точного планирования стадий и этапов выполнения проекта, прогнозирования продвижения проекта, и могут своевременно и адекватно реагировать на возникающие проблемы. С уменьшением возможных отклонений от заданных сроков, стоимости и качества в процессе выполнения проекта их возможность предвидения результатов постоянно возрастает.

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

Четвертый и пятый уровни редко встречаются в индустрии ПО. Так, если третьего уровня достигло в мире несколько сотен компаний, то фирм пятого уровня (по информации SEI на 2002 г.) насчитывалось 62, а четвертого - 72. При этом отметим, что объявляют о своем уровне зрелости далеко не все компании. Одни не заинтересованы в афишировании своих организационных технологий, другие выполняют сертификацию просто под давлением заказчика.

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

Последняя версия СММ 1.1 в основном ориентирована на крупные компании, занимающиеся реализацией больших проектов, но она вполне может использоваться и группами из двух-трех человек или отдельными программистами для выполнения небольших проектов (продолжительностью до трех месяцев). В таких случаях модель СММ может сыграть жизненно важную роль, поскольку поступление новых заказов во многом определяется качеством реализации предыдущих проектов. Маленькие группы вполне удовлетворятся уровнем 2, так как для небольшого проекта отклонение от срока на пару недель непринципиально.

С 2002 г. официально распространяется специальная интеграционная версия CMMI. Это новая разработка SEI, охватывающая все аспекты деятельности компании: от разработки и выбора подрядчика до обучения, внедрения и сопровождения. Кроме того, модель CMMI расширена подходами из системной инженерии. В эту модель вошли наработки, сделанные в ходе проектирования версии СММ 2.0 (она не была закончена), основные изменения в которой были направлены на уточнение процессов для компаний четвертого и пятого уровней, что наиболее актуально для крупномасштабных американских проектов.

Модель СММ достаточно весома и важна, однако не стоит применять ее как единственную основу, определяющую весь процесс создания ПО. Она была предназначена в основном для ком­паний, которые занимаются разработкой ПО для Министерства обороны США. Эти системы отличаются большими размерами и длительным сроком эксплуатации, а также сложностью интерфейса с аппаратным обеспечением и другими системами ПО. Над созданием таких систем работают достаточно большие коллективы программистов, которые должны подчиняться требова­ниям и стандартам, разработанным Министерством обороны.

К недостаткам СММ относятся следующие:

1. Модель сосредоточена исключительно на управлении проектом, а не на процессе создания программного продукта. В модели не учтены такие важные факторы, как использование определенных методов, например прототипирования, формальных и структурных методов, средств статического анализа и т.п.

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

3. Не определена область применения модели, хотя авторы признают, что она является универсальной и подходящей всем организациям. Однако авторы не дают четкого разграничения организаций, которые могут или не могут внедрять СММ в свою деятельность. Небольшие компании находят эту модель слишком бюрократичной. В ответ на эту критику были разработаны стратегии совершенствования технологического процесса для малых организаций.

Главной целью создания модели СММ было намерение Министерства обороны США оценить возможности поставщиков ПО. На данный момент пока не существует четких требований к достижению определенного уровня развития организаций-разработчиков. Однако принято считать, что у организации, достигшей высокого уровня, больше шансов выиграть тендер на поставку ПО. В качестве альтернативы СММ предлагается обобщенная классификация процессов совершенствования технологической зрелости, которая подходит для большинства организаций и программных проектов. Можно выделить несколько общих типов процессов совершенствования.

1. Неформальный процесс. Не имеет четко выраженной модели совершенствования. Его с успехом может использовать отдельная команда разработчи-

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

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

3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными инструментальные средства поддержки проектирования и анализа процессов (CASE-средства).

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

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

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

Рис. 1.8. Применимость процессов совершенствования

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

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

Модель СММ не уникальна. Почти каждая крупная компания развивает собственные технологии создания ПО, иногда эти технологии становятся общедоступными и очень популярными. Широкая известность модели СММ связана с ее государственной поддержкой, но реальная эффективность СММ критикуется многими ведущими экспертами. Один из основных недостатков СММ связан с излишне жестким требованием не отклоняться от принципов данной модели, даже если здравый смысл подсказывает обратное. Подобные претензии на владение абсолютной истиной не могут не вызвать настороженности, поэтому в среде малых и средних компаний более популярны подходы, оставляющие гораздо больше свободы для индивидуального и коллективного творчества. Рассматриваемая далее методика SPMN занимает промежуточное место между жесткими, «тяжелыми», эффективными для крупных организаций решениями типа СММ и максимально гибкими технологиями. Она представляется оптимальным вариантом для фирм, которые, с одной стороны, хотят как можно быстрее упорядочить свою управленческую деятельность, а с другой стороны, планируют в перспективе выйти на международный уровень, где сертификация по СММ крайне желательна.