Лекция 11. Модели жизненного цикла

в некоторых реальных методологиях

программирования

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

Ключевые слова: методология программирования, инструменталь­ная поддержка методологии, реальные методологии, модель жиз­ненного цикла, RUP, модель процессов MSF, каскадная модель, спиралевидная модель, методологии быстрого развития, итератив­ное наращивание, сертификация команды разработчиков, методо­логия экстремального программирования, адаптивная разработка, непредсказуемость программного проекта, обдумывание, сотрудни­чество, обучение.

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

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

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

Модель rup

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

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

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

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

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

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

В качестве примера рассмотрим следующую ситуацию.

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

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

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