Уровни технологической зрелости организации

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

Эти тенденции не исчезли и в последующий период. Так проведенные в 1995г. компанией Standish Group исследования на базе 364 американских компаний и итогов выполнения более 23 тысяч проектов, а также повторные исследования в 1998г. дали следующие результаты – см. табл. 8.3.

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

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

Таблица 8.3 Результаты исследований Standish Group

Результаты проектов	Доля результата в общем числе проектов
1995г.	1998г.
Проект завершен в срок без превышения запланированного бюджета и с реализацией всех заданных функциональных требований	16,2%	26%
Проект завершен с опозданием, расходы превысили запланированный бюджет, функции реализованы не в полном объеме	52,7%	46%
Проект аннулирован до его завершения	31,1%	28%

 

Следует отметить, что со временем зарождения программирования накоплен значительный опыт в области совершенствования технологических процессов разработки, внедрения и эксплуатации ПО. Так в начале 90–х годов ХХ века американский институт программной инженерии сформулировал модель технологической зрелости проектной организации СММ (Capability Maturity Model), позволяющую определить уровни технологической зрелости и их отличительные черты. Данная модель успешно прошла в течение десяти лет апробацию в целом ряде организаций, выступающих в роли заказчиков, поставщиков ПО, разработчиков ПО «под заказ» и т.д.

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

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

В рамках модели СММ принято выделять пять условий технологической зрелости организации – см. рис. 8.6.

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

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

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

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

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

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

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

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

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

6. измерения и анализ;

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

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

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

1. Помимо процессов, присутствующих на втором уровне СММ, на третьем уровне добавляются следующие процессы:

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

3. интеграция продукта

4. верификация

5. аттестация

6. стандартизация процессов организации

7. обучение

8. интегрированное управление проектом

9. управление рисками

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

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

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

К процессам, реализуемым на втором и третьем уровнях модели СММ, добавляются следующие:

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

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

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

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

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

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

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

2. причинно–следственный анализ и разрешение проблем.

Для этого уровня характерно последовательное совершенствование процессов создания и сопровождения ПО.

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

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

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

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

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

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

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

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

Рисунок 8.8. Обобщенное представление процесса

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

возможностью фиксации лучшего из накопленного опыта аналогичной деятельности;

возможностью сокращения затрат ресурсов;

возможностью сокращения сроков работы;

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

обеспечением объективности взаимоотношений между участниками процессов;

возможностью создания массового производства продукта.

В отношении процессов применим так называемый «цикл Деминга» (в 20–е годы ХХ века предложен Уолтером Шухартом, этот подход популяризовал Деминг) или цикл PDCA – см. рис. 8.9.

Рисунок 8.9. Схематическое представление цикла PDCA (цикла Деминга)

В рамках цикла Демминга предусмотрен следующий порядок действий:

P – (Plan) – установить процессы и их последовательность, необходимые для получения результатов в соответствии с требованиями потребителя, определить ресурсы, необходимые для реализации процессов;

D – (Do) – внедрить процессы, запустить их в действие;

C – (Check) – контроль (мониторинг) продукции и процессов с целью оценки состояния и выявления отклонений;

A – (Act) – воздействовать с целью достижения результата (ликвидация отклонений) и совершенствования процессов.

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

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