Результативность программистской проектной деятельности

Уровни зрелости процессов разработки программного обеспечения

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

Этот аспект замечен и зафиксирован в модели зрелости процессов разработки программного обеспечения SW-CMM [18] (см. лекцию 5). Поскольку одной из основных целей модели является построение организационной процедуры сертификации организаций, разрабатывающих программное обеспечение, она исходит из стандартизованной классификации организаций, распределения их по нескольким уровням. На каждом из уровней в принципе может достигаться определенная результативность проектов, отслеживание которой - задача специальной деятельности, обеспечивающей процедуру сертификации достоверной информацией. Исходным материалом для этой деятельности являются все рабочие продукты проектов, в частности документы, отражающие процесс развития и контроля реализации проекта. Ее основной сертификационный результат - отнесение организации к одному из пяти уровней зрелости:

1. Начальный (initial) уровень. Находясь на начальном уровне, организация обычно не может обеспечить устойчивый процесс разработки и сопровождения программного обеспечения. В организации отсутствует культура управления, из-за неэффективного планирования и плохого согласования работ продуктивность производственного процесса непредсказуема. Успешные проекты возможны, но как рабочие продукты оформляются лишь результаты целевой группы.
2. Повторяемый (repeatable) уровень. На этом уровне планирование и управление новым проектом базируются на опыте работы с подобными проектами. Характерным качеством ведения проектов на повторяемом уровне является возможность воспроизведения успешных практик прежних проектов. Если в организации как рабочие продукты оформляются лишь результаты целевой группы, то единственная возможность для такого воспроизведения - это назначение на новые проекты менеджеров, которые уже хорошо зарекомендовали себя в предыдущих проектах. Это тот случай, когда процессы развития проекта и наблюдения не отражаются в рабочих продуктах, а представлены лишь в фольклорном варианте. Осознание неустойчивости такого положения приводит к стремлению все более точно фиксировать опыт документально. Иными словами, повторяемый уровень в конечном итоге диктует необходимость формирования рабочих продуктов для всех трех групп.
3. Определенный (defined) уровень, или уровень становления. На этом уровне в организации принят стандарт проведения разработки и сопровождения программного обеспечения, в рамках которого обеспечена интеграция процессов построения и управления. Разработка и сопровождение полностью документированы, что позволяет организовать наблюдение и контроль выполнения проектов. В материалах CMM такой стандарт называется стандартным производственным процессом организации. Для конкретных проектов стандартный производственный процесс адаптируется с целью учета его особенностей, в результате чего определяются критерии готовности, качества и т.д., а также механизмы контроля. За счет ясной определенности процессов руководство организации получает точную картину развития проектов. Продуктивность производственного процесса на определенном уровне характеризуется как стандартная и согласованная. На этом уровне к рабочим продуктам каждой из групп предъявляются дополнительные требования: они должны быть представлены таким образом, чтобы специфика проекта явно отделялась от стандартизованного содержания, то есть чтобы при производстве рабочих продуктов максимально повышалась возможность их независимого от проекта применения.
4. Управляемый (managed) уровень. Согласно CMM, этот уровень характеризуется внедрением в организацию количественных показателей качества как для программных продуктов, так и для процессов их разработки. Производственные процессы управляемого уровня оснащены средствами для проведения четко определенных и согласованных измерений. Продуктивность производственного процесса на управляемом уровне характеризуется как предсказуемая, так как процесс функционирует в заданных и измеряемых пределах. Иначе говоря, предполагается, что за счет количественных показателей качества удается организовать наблюдение за любой проектной деятельностью, которое позволяет удерживать траекторию в области допустимости. Дополнительные требования к рабочим продуктам этого уровня заключаются в том, что конкретизируется и получает процесс развития проекта, а так же статус обязательного стандарта группы продуктов, отражающих измерения и наблюдение за проектом^{1Представляется,что количественные показатели и измерения полезны для оценки результативности проектов.Однако вопрос в том,что и как нужно измерять.Многочисленные попытки ответить на него таким образом,чтобы в получаемых показателях качество отражалось с функциональной точностью,предпринимались в течение более чем тридцати лет,но,к сожалению,к ощутимым результатам они не привели.Неудачи связаны не только с тем,что понятие "качество" не определено строго,что оно меняется от методологии к методологии,что субъективная составляющая качества превалирует над объективной.Их причины глубже и принципиальнее.Не вдаваясь в детали обсуждения этого предмета,которое выходит за рамки нашего курса,отметим,что коренные причины проблем количественных показателей обусловлены существенной креативностью программистской деятельности,а надежных критериев качества любой деятельности такого рода просто не существует.Тем не менее вместо точных измерений в обычной практике прибегают к оценкам,что зачастую (но далеко не всегда!)ока зывается достаточным.}.
5. Оптимизирующий (optimizing) уровень. Работа над проектами ведется как на управляемом уровне, но организация в целом сосредоточена на усовершенствовании производственного процесса. Она обладает средствами выявления слабых мест процесса и его улучшения с целью предотвращения дефектов. Внедряются новшества, использующие передовые методы программной инженерии, которые распространяются для улучшения качества разработок всех проектов. В рамках оптимизационного уровня налажены механизмы оценки не только выполненных проектов (это идет от предыдущего уровня), но и возможных новаций во всех аспектах проектирования^{2См.замечания по поводу количественных показателей и измерений качества в предыдущей сноске.}. Таким образом, ассортимент используемых рабочих продуктов не ограничивается тем, что появляется по ходу выполнения целевых проектов. Необходимые для оптимизирующего уровня продукты могут разрабатываться специально. Несколько иронично оптимизирующий уровень иногда называют "нирваной проектной деятельности" [47].

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

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

увеличить изображение
Рис. 18.1. Лестница развития зрелости организации (из статьи [47])

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

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

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

увеличить изображение
Рис. 18.2. Формирование методов и методик анализа и обобщения решений

К сожалению, на этом пути встречаются три проблемы.

• Искушение распространения удачного опыта за пределы его области применимости.

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

  В качестве примера рассмотрим каноническую для объектно-ориентированного подхода с использованием UML рекомендацию составлять три вида диаграмм классов: концептуальные, специфицирующие и реализационные, которые отражают разные стадии уточнения разрабатываемой системы классов [25]. Обычно указывают, какие из средств UML нужно применять для диаграмм каждого вида. Однако UML -нотация - это универсальная система, и нет никакой возможности объяснить ей, что вот сейчас составляются концептуальные диаграммы, а потом нам потребуются специфицирующие и далее реализационные диаграммы. Во всех трех случаях используются одни и те же средства, а значит, один метод, различия классов диаграмм системно не поддерживаются, т.е. методическая рекомендация остается на уровне пожелания, которое могут игнорировать.
• Многие методы просто противоречивы и при их объединении в одной методике вместо ожидаемого дополнения достоинств происходит их нейтрализация и пышным цветом расцветают недостатки объединяемых методов.

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

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

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

  Если бы программирование можно было рассматривать как императивную деятельность, то обязательность требований к процессу была бы вполне мотивирована^{3В связи с этим хочется привести аргумент из реального спора с одним из апологетов императивности программистской деятельности:"Мы вправе не знать,почему летает самолет,но если будем поступать так-то и так-то,как поступают при строительстве самолетов в компании "Боинг ",то в результате получим машину,которая непременно полетит.Также и с программами:мы знаем,какие практики хорошо себя зарекомендовали,а потому давайте следовать им неукоснительно ".На возражение,что в этом случае мы сможем строить только такие программы,которые придуманы ранее,был ответ (не лишенный логики!):"Именно это и требуется со стороны практического применения программных систем ".}. Однако, как мы уже отмечали в разделе "Жесткие и гибкие стратегии в методологиях программирования" лекции 5, креативность процесса разработки программ делает эту мотивацию несостоятельной. Обязательные требования к процессу не дают преимуществ, а лишь усложняют его, делая "монументальным", громоздким и негибким. Естественная реакция на такое положение - отказ от тяжеловесных стандартов - отражена в концепциях быстрых методологий, зафиксированных в Agile Manifesto [31].

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