Модели жизненного цикла в некоторых реальных методологиях программирования

Хорошая методология никогда не будет ограничиваться популяризацией какой-либо идеи, метода или инструментария, она предлагается как комплексная поддержка деятельности исполнителей проекта. Однако часто происходит подмена: вместо методологии фактически предлагается набор инструментов, способных в той или иной степени поддерживать некоторые методологии, а о границах применимости не упоминают вовсе. Единственный плюс, который можно в этом усмотреть, — возможность поддержки разных методологий. Но от инструментов до реальной поддержки — долгий путь, гораздо более неопределенный, чем разработка инструментария. И это, к сожалению, обычно замалчивается, что, впрочем, вполне объяснимо стремлением не ограничивать сферу применения предлагаемых средств рамками конкретной методологии.

Это, пожалуй, основная причина затруднений при попытках применения методологий в конкретных условиях. Ситуация только запутывается, когда для такого применения можно задействовать развитую CASE-систему: правила использования ее средств неявно диктуют для конкретного проекта неопределенную методологию, что, как правило, пагубно отражается на качестве работ проекта.

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

Модель RUP

Ранее мы упомянули о том, что сегодня 51% программных разработок применяют CASE-системы, поддерживающие RUP — Rational Unified Processing [30]. Уже одного этого достаточно, чтобы обратить внимание на данный подход и исследовать, за счет чего он обеспечивает ощутимую пользу для практических разработок. Безусловно, достоинством RUP является предлагаемый инструментарий моделирования различных аспектов реализуемого программного обеспечения, и именно этот инструментарий применяется чаще всего. Он привлекает разработчиков выразительностью, поддержкой согласованного использования систем моделей, связываемых общей системой понятий.

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

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

Модель задается в виде матрицы интенсивностей функций, выполняемых на этапах (фазах), которые проецируются на итерации (см. рис. 11.1). Авторы CASE-систем, поддерживающих RUP, неизменно подчеркивают иллюстративный стиль изображения интенсивностей. Для каждой итерации можно указать, в какой фазе она находится в данный момент (см. серый овал на рисунке), а также какая рассматривается функция (см. жирную точку и стрелку, ведущую к очередной фазе).

увеличить изображение
Рис. 11.1. Модель жизненного цикла RUP

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

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

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

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

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

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