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

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

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

Институт технологии программирования

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

В начале 80-х годов правительство США задалось таким вопросом: почему программные проекты, которые делаются по его заказам, либо не выполняются вообще, либо выполняются, но с огромным отставанием по срокам, либо требуют бюджетов, существенно превышающих первоначально запланированные? К этому времени уже было известно, как добиться улучшения качества систем, построенных исключительно на аппаратуре (например промышленность Японии, Кореи, Западной Европы). Но когда в сложных системах появился относительно новый компонент – программное обеспечение, то их качество стало резко снижаться; стали возникать ситуации, когда невозможно в срок закончить разработку, ресурсы поглощаются и неизвестно, когда это кончится. Поэтому и хотели понять, как поступать в новой ситуации, если в системе имеется существенный программный компонент.

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

Первым результатом Института стал отчет "Метод для определения способностей подрядчиков в области технологии программирования" (сентябрь 1987 г.), положивший начало дальнейшим исследованиям в этой области.

Пятиуровневая модель зрелости способностей

Эта модель (CMM – Capability Maturity Model) была впервые предложена Институтом технологии программирования в 1989 г. [1] как первый важный результат в решении сформулированной выше задачи и с тех пор несколько раз уточнялась. Модель прежде всего нацелена на создание программного обеспечения. Она не связана с материальным производством или с другими видами деятельности, хотя общие принципы управления, положенные в ее основу, практически одинаковы для самых разных видов человеческой деятельности. Однако нацеленность на разработку именно программного обеспечения имеет свои особенности. Важно, что модель ²не говорит² как выполнять ту или иную работу, она ²говорит² только что надо делать, а решения как делать оставляются на усмотрение исполнителей. Модель ничего ²не говорит², с помощью каких инструментов надо выполнять разработку программного продукта; опять все зависит от конкретной задачи, от конкретного коллектива, от самой разработки. Модель сделана как дополнение к уже существующим стандартам в области технологии программирования, таким как QSR, PDA и ISO 9000, и во многом с ними согласована.

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

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

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

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

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

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

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

Рис. 2. Пять уровней зрелости

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

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

Рис. 1. Структура модели CMM

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

Уровни зрелости

В модели CMM различается пять уровней зрелости, последний, пятый, является наивысшим. Многие разработчики ПО в США стремятся к официальной аттестации на тот или иной уровень. В 1994 г. большинство разработчиков находились на первом или втором уровне, относительно немного на третьем и единицы на четвертом. В конце 1997 г. свыше 30 тысяч компаний достигли третьего и четвертого уровня и около 30 компаний были официально сертифицированы на пятый уровень (среди них подразделения по разработке ПО компаний IBM, Моторола, Боинг). С 1993 г. в США действует положение, согласно которому к любым конкурсам на получение государственных заказов на разработку ПО могут быть допущены только те разработчики, которые были официально аттестованы на требуемый данным конкурсом уровень и получили соответствующий сертификат.

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

1. Начальный (initial) процесс не имеет какой-либо устойчивой структуры или про него просто ничего не известно.

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

(1) Управление требованиями (RM – Requirements Management): цель – установить единое с заказчиком понимание требований к данному проекту, которое служит основой для последующего планирования и отслеживания; отношения с заказчиком зависят от следования процессу управления изменениями, как он определен в управлении конфигурацией. Здесь под словом требование понимаются понятия требования и спецификации. Требованиями называются более или менее смутные пожелания заказчика, что должен делать конечный продукт; в то время как спецификация – это производное от требования, но оно уже более четко и точно формулирует конкретное свойство продукта. Поэтому управление требованиями – это целый куст деятельностей, связанных с переходом от требований к конкретным и точным спецификациям на данный программный продукт, учитывающий их постоянное развитие и изменение.

(2) Планирование проекта (PP – Software Project Planning): цель – установить реалистичные планы для выполнения проекта и управления им. Это тоже целый куст деятельностей, связанных с разработкой различных планов, которые в дальнейшем постоянно используются как средство управления проектом.

(3) Отслеживание проекта (PT – Software Project Tracking and Oversight): цель – установить надежную отображаемость проекта таким образом, чтобы руководство могло принимать эффективные шаги всякий раз, когда выполнение проекта заметно отклоняется от планов. Это тоже куст деятельностей, связанных с постоянным контролем того, как идет процесс в проекте, насколько он соответствует утвержденному плану. Отслеживание необходимо для получения как можно более раннего оповещения об отставании, с тем чтобы можно было вовремя принять поправочные действия. В АОЗТ "Информационные деловые услуги" (ИДУ) отслеживание выполняется еженедельно. Каждую неделю все разработчики пишут отчет о соответствии плану того, что сделано, и показывают определенные характеристики того, что сделано, из которых сразу видно, по плану ли идет процесс или начинаются отклонения от него. А если выявляются отклонения, то собирается совещание, на котором принимаются определенные решения, как поправить ситуацию, которая только начинает ухудшаться.

(4) Управление субподрядчиками (SM – Subcontractor Management): цель – правильно выбрать субподрядчиков и в дальнейшем эффективно управлять их деятельностью; данная область имеет в себе элементы управления требованиями, планирования и отслеживания по отношению к субподрядчику, которые должны согласовываться с обеспечением качества и управлением конфигурацией в данном проекте. Иногда ее может не быть, в том случае, когда проект выполняется только силами данного разработчика.

(5) Обеспечение качества (QA – Software Quality Assurance): цель – постоянно давать руководству картину используемого процесса и создаваемого продукта; входит как составная часть в большинство процессов разработки и управления. Это большой куст деятельностей, связанных с обеспечением требуемого качества конечного продукта. У разработчика должен быть специальный план по обеспечению качества, в котором все эти деятельности должны быть прописаны и взаимоувязаны.

(6) Управление конфигурацией (CM – Software Configuration Management): цель – установить и постоянно поддерживать целостность разрабатываемого программного продукта на протяжении всего жизненного цикла; входит как составная часть в большинство процессов разработки и управления. Как и в случае обеспечения качества, разработчики составляют специальный план по управлению конфигурацией, которые взаимоувязывают все предусмотренные для этого деятельности.

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

(7) Нацеленность процесса (PF – Organization Process Focus): цель – создать определенную организационную дисциплину во всех видах деятельности для повышения способностей данной организации по созданию ПО. Первоочередным результатом является создание некоторого набора элементов процесса для его определения, которые используются проектами в интегрированном управлении. Формулируются цели, ради которых данный процесс вводится, обеспечивается ясное понимание этих целей разработчиками.

(8) Определение процесса (PD – Organization Process Definition): цель – разработать и постоянно поддерживать необходимый набор элементов процесса, которые улучшают его производительность по всем проектам и создают основу для накопления долгосрочных заделов для данной организации. Эти элементы создают прочный фундамент, который может быть задействован через такие механизмы, как непрерывное повышение квалификации. Создается так называемая книга процесса, в которой описаны все деятельности и процедуры для выполнения.

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

(10) Интегрированное управление (IM – Integrated Software Management): цель – соединить деятельности по разработке и управлению в единый согласованный процесс, который настраивается исходя из типового процесса данной организации и связанных с ним элементов процесса, описанных в его определении. Такая подгонка основывается на деловой среде и технических потребностях данного проекта, как это описано в технологии разработки. Интегрированное управление вырастает из ключевых областей планирования и отслеживания второго уровня зрелости.

(11) Технология разработки (PE – Software Product Engineering): цель – постоянно следовать хорошо определенному технологическому процессу, который объединяет все технологические деятельности по эффективному созданию корректных, согласованных программных продуктов. Технология разработки описывает технические виды деятельности (анализ требований, проектирование, кодирование, тестирование).

(12) Межгрупповая координация (IC – Intergroup Coordination): цель – создать средство для того, чтобы отдельные группы разработчиков могли активно взаимодействовать друг с другом для эффективного удовлетворения потребностей заказчика. Межгрупповая координация является междисциплинарным аспектом интегрированного управления, которое выходит за рамки чисто технологические; не только сам процесс разработки сводится в единое целое, но и взаимодействия между группами разработчиков также должны координироваться и управляться.

(13) Товарищеские обзоры (PR – Peer Reviews): цель – как можно раньше и с наибольшей эффективностью устранять дефекты из программных продуктов; важным следствием является развитие лучшего понимания разрабатываемых продуктов и дефектов, которые могут быть предотвращены. Это важный и эффективный технологический прием, который входит в технологию разработки и может быть реализован через инспекции по Фейгану, структурные разборы или иные методы коллегиальных обзоров.

4. Управляемый (managed) – появляется возможность активно воздействовать на сроки разработки и качество конечного программного продукта. Добавляются следующие две ключевые области.

(14) Количественное управление процессом (PA – Quantitative Process Management): цель – количественно управлять производительностью процесса разработки, которая представляет фактические достижения в следовании процессу. Суть в выявлении особых причин отклонения от измеряемых характеристик устойчивого процесса и в соответствующей корректировке условий, которые приводят к возникновению такого отклонения. Количественное управление процессом прилагает обширную метрическую программу к деятельностям из определения процесса, интегрированного управления, межгрупповой координации и товарищеских обзоров. Это означает, что все управление процессом, все воздействия на него осуществляются с применением метрик.

(15) Управление качеством (QM – Software Quality Management): цель – разработать количественное понимание качества программных продуктов и достичь конкретных показателей по качеству. Управление качеством применяет обширную метрическую программу к деятельностям, описанным в технологии разработки. Если на втором уровне зрелости было только обеспечение качества, то есть только добивались того уровня, который был задан, то на четвертом уровне качество уже управляемо. Это принципиально новая возможность.

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

(16) Предотвращение дефектов (DP – Defect Prevention): цель – выявлять причины дефектов и предотвращать их повторное возникновение. Проводится анализ дефектов, выявляются их причины, и изменяется сам процесс разработки, как это описывается в интегрированном управлении; изменения процесса, имеющие общее значение, переходят на другие проекты, как описывается в управлении изменениями процесса. Существенно, что происходит именно предотвращение дефектов, а не исправление допущенных ошибок и создаются условия, при которых дефекты вообще не возникают.

(17) Управление изменениями технологии (CI – Technology Change Management): цель – определять преимущества новых технологий (например инструментальных средств, методов и процессов) и переносить их в организацию некоторым упорядоченным способом, как описано в управлении изменениями процесса. Суть в эффективном внедрении новшеств в постоянно меняющемся мире, поскольку добиться хороших результатов нельзя, не совершенствуя постоянно и не внедряя все новые и новые технологии.

(18) Управление изменениями процесса (PC – Process Change Management): цель – постоянно улучшать процесс в данной организации с намерением улучшать качество создаваемых продуктов, повышать производительность и уменьшать сроки разработки. Управление изменениями процесса берет отдельные пошаговые улучшения из предотвращения дефектов и управления изменениями технологии и затем делает их доступными для всей организации. Такое самосовершенствование должно происходить под управлением самого процесса так, чтобы процесс постоянно двигался в сторону все большей своей оптимизации.

Определение уровня зрелости

Для определения уровня зрелости используется экспертная оценка по десятибалльной шкале. Чтобы поставить оценку, группа экспертов обследует организацию, встречается и беседует с разработчиками и руководством, изучает представленную ей документацию по проводимым разработкам. Оценивание каждого фактора проводится по трем измерениям: подход, внедренность, результат. Десятибалльная шкала разбивается на шесть ступеней со следующими нечеткими обозначениями: плохо (poor) – 0; слабо (weak) – 2; посредственно (fair) – 4; условно удовлетворительно (marginally qualified) – 6; удовлетворительно (qualified) – 8; превосходно (outstanding) – 10.

Подход определяет то, как данный фактор воспринимается непосредственно теми, кого он касается, и характеризуется следующими состояниями:

(0) – плохо – руководство не видит необходимости; у организации нет возможности; у организации нет желания; данная деятельности не очевидна;

(2) – слабо – руководство начало признавать необходимость; начали создаваться необходимые условия для ведения данной деятельности; некоторые подразделения организации могут вести данную деятельность;

(4) – посредственно – имеется большое, но не всеохватное желание руководства; имеется план введения данной деятельности в практику; реализованы несколько из необходимых условий для ее ведения;

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

(8) – удовлетворительно – полное желание руководства; большинство руководителей выступают как активные проводники данной деятельности; деятельность стала составной частью процесса; поддерживающие необходимые условия делают легким ведение данной деятельности на практике и поощряют его;

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

Внедренность характеризует то, насколько широко данная деятельность распространена в организации:

(0) – плохо – никакое подразделение не ведет данную деятельность; никакое подразделение не проявляет к ней интереса;

(2) – слабо – фрагментное использование от случая к случаю; несистематическое использование; имеет распространение в некоторой части организации; ограниченный контроль за использованием;

(4) – посредственно – менее фрагментное использование; более систематическое использование; имеет распространение в большей части организации; контроль и проверка использования в нескольких частях организации;

(6) – условно удовлетворительно – внедрена в большей части организации; в основном систематическое использование по всей организации; контроль и проверка использования в большинстве подразделений;

(8) – удовлетворительно – внедрена практически во всей организации; систематическое использование практически во всей организации; контроль и проверка использования практически во всей организации;

(10) – превосходно – повсеместное и систематическое распространение по всей организации; систематическое использование в течение заметного времени во всей организации; контроль и проверка использования для всех подразделений организации.

Наконец, результат характеризует то, как сказывается данная деятельность на практических результатах организации:

(0) – плохо – безрезультатно;

(2) – слабо – отдельные разрозненные результаты; несистематические результаты; некоторые свидетельства о действенности для некоторой части организации;

(4) – посредственно – систематические и положительные результаты для некоторых подразделений организации; несистематические результаты для остальных подразделений;

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

(8) – удовлетворительно – положительные результаты, допускающие измерение, практически во всей организации; систематически положительные результаты в течение заметного времени практически во всей организации;

(10) – превосходно – превышение требований; систематические результаты мирового уровня; другие разработчики перенимают опыт.

Для примера приведем анкету по оцениванию ключевой области "отслеживание проекта", которая применялась при оценивании АОЗТ ИДУ на третий уровень зрелости в 1995 г. Каждая деятельность оценивалась по описанной выше десятибалльной шкале, после чего выводилась средняя оценка. Анкета содержала 12 вопросов.

1) Используется ли задокументированный план разработки для отслеживания деятельности по разработке ПО и подготовке отчетов о состоянии проекта?

2) Проводит ли обзор и утверждает ли руководство организации все намерения отдельных лиц и внешних к организации групп, а также их изменения?

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

4) Отслеживается ли размер проектов и предпринимаются ли действия по исправлению положения?

5) Отслеживается ли стоимость ведения проектов и предпринимаются ли действия по исправлению положения?

6) Отслеживаются ли критические компьютерные ресурсы и предпринимаются ли действия по исправлению положения?

7) Отслеживается ли график ведения проектов и предпринимаются ли действия по исправлению положения?

8) Отслеживаются ли деятельности технического характера при ведении проектов и предпринимаются ли действия по исправлению положения?

9) Отслеживаются ли на протяжении всего времени разработки технические риски, риски по стоимости, ресурсам и графику?

10) Ведутся ли записи фактических данных измерений и данных по перепланированию деятельностей по отслеживанию проекта для использования разработчиками и руководителями?

11) Совершают ли разработчики и руководители регулярные обзоры для отслеживания продвижения в технических вопросах, планировании, исполнении и в решении проблем и для их соотнесения с планом разработки?

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

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

Данная модель на сегодняшний день прошла практическую проверку во множестве организаций. Она построена на проверенных принципах [1-8].

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

Список литературы

1.   Paulk M.C., Curtis B., Chrissis M.B., Weber Ch.V. Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. - Pittsburgh: Software Engineering Institute, 1993. - 533 p.

2.   Boehm B.W. Software Engineering Economics. - Englewood Cliffs: Prentice Hall, 1981. - 767 p. – Русс. пер.: Боэм Б.У. Инженерное проектирование программного обеспечения/ Пер. с англ. - М.: Радио и связь, 1985. - 512 с.

3.   Brooks F.P.Jr. The Mythical Man-Month. - S.L.: Addison-Wesley, 1975. – Русс. пер.: Брукс Ф.П.мл. Как проектируются и создаются программные комплексы. Сер. Библиотечка программиста. - М.: Наука, 1979. - 152 с.

4.   DeMarco T. Controlling Software Projects. - Englewood Cliffs: Prentice Hall, 1982.- 284 p.

5.   Grady R.B. Practical Software Metrics for Project Management and Process Improvement. - Englewood Cliffs: Prentice Hall, 1992. - 270 p.

6.   Humphrey G. Managing the Software Process - Reading: Addison-Wesley, 1989. - 494 p.

7.   IEEE Standards Collection. Software Engineering, 1993 Edition. - New York: IEEE, 1993. - 952 p.

8.   Myers G.J. The Art of Software Testing. - New York: John Wiley & Sons, 1979. - 177 p.