Определение программного инжиниринга в модели SEI CMM

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

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

- программный инжиниринг (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) культура должна способствовать внедрению ролевых моделей и наград.

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