Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

РАЗРАБОТКА И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ПОДДЕРЖКИ ПО

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

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

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

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

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

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

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

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

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

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

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

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

Организация взаимодействия и контроля

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

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

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

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

 необходимость передачи материала заставляет разработчика обеспечить полную завершенность работы;

 при просмотре материала «со стороны» легче обнаружить ошибки;

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

 подробное ознакомление со смежными работами расширяет знания обо всей разрабатываемой системе.

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

От проведения просмотра ожидается следующий эффект:

 во время обсуждения замечаний происходит обмен опытом между участниками совещания;

 дополнительное информирование участников о деталях разрабатываемой системы;

 укрепляется ощущение участия в разработке всей системы каждого из исполнителей;

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

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

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

 соответствует ли состав предъявленной документации требованиям технического задания и принятой технологии;

 имеется ли возможность на основании документации без привлечения разработчиков понять и оценить содержание разработки;

 соответствуют ли функции, реализованные на данном этапе, функциям, предусмотренным в предыдущей или исходной точке;

 достаточна ли документация для проведения работ на следующем этапе разработки;

 имеются ли ошибки (какие и в каком количестве), без устранения которых нельзя судить о законченности этапа разработки;

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

 согласована ли разработка со смежными разработками с точки зрения возможности ее испытаний и сдачи заказчику;

 реален ли график проведения работ следующего этапа с точки зрения сроков в условиях имеющихся ресурсов.

В результате проведения контроля могут быть приняты следующие решения:

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

 требуются существенные доработки в рамках выполненного этапа с повторным контролем полученных результатов.

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

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

Организация коллективных библиотек разработки

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

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

К вспомогательным и стандартным средствам относятся типовые процедуры, типовые имитаторы, вспомогательные программы для проверки и отладки и т.д.

Библиотеки средств программирования доступны программистам-исполнителям только для чтения.

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

Рис. 65. Структура внутренних библиотек разработки

Структура внешних библиотек проиллюстрирована на рис. 66.

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

Рис. 66. Структура внешних библиотек разработки

Картотека должна отражать актуальное состояние библиотек и служит для поиска материала и регистрации отсутствующих материалов. Для удобства поиска картотека делится на секции и классы.

Карточки в каждом классе упорядочены по именам объектов хранения.

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

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

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

 регистрация движения всех библиотечных материалов;

 выполнение типовых заданий программистов на ЭВМ;

 профилактика сохранности информации на машинных носителях.

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

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

Стандарт разработки MSF: Team model

Рассмотрим модель, входящую в состав стандарта программного обеспечения Microsoft Solution Framework - модель организации коллектива разработчиков Team model. Это название лучше всего перевести как набор подходов к решению. Предлагается набор методик, которые можно использовать для организации работы в области, связанной с разработкой ПО.

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

 работа небольшими коллективами, объединенными для реализации одного продукта;

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

 учет возможных неблагоприятных факторов до их возникновения и планирование активности с учетом возможных неприятностей;

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

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

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

Стандарт разработки MSF: Process model

Рассмотрим центральную модель, входящую в состав стандарта разработки программного обеспечения компании Microsoft - модель организации процесса разработки (Process model).

Даже самый лучший коллектив разработчиков, организованный в соответствии с рекомендациями лучших стандартов, обречен на неуспех, если он не организует свою деятельность правильным образом. Поэтому модель организации процесса разработки является центральной в совокупности моделей стандарта разработки программного обеспечения Microsoft Solution Framework. Рассмотрим основные отличия процесса разработки с точки зрения MSF от традиционных представлений и проанализируем различные элементы этой модели.

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

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

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

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

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

Рrocess model MSF позволяет организовать работу так, чтобы постоянно реагировать на требования заказчиков, наилучшим образом соответствовать им, постоянно держать заказчиков в курсе процесса разработки.

CMM: Capability Maturity Model, CMM

В середине 80-х годов институтом разработки программного обеспечения университета Карнеги-Меллона (Software Engineering Institute) была создана концепция моделей зрелости процессов (Capability Maturity Model, CMM) разработки в различных областях человеческой деятельности: прикладного и системного программного обеспечения, управления персоналом, выбора покупного программного обеспечения и т.д. Эти модели состоят из набора описаний для различных уровней зрелости анализируемого процесса. Каждому уровню зрелости соответствует определенный набор, так называемых, ключевых практик или подпроцессов, наличие или отсутствие которых и определяет принадлежность существующего положения дел к тому или иному процессу.

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

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

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

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

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