учебники, программирование, основы, введение в,
Оформляется лицензия СКЗИ с полными консультациями и по оптимальным ценам.

 

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


Хорошая методология никогда не будет ограничиваться популяризацией какой-либо идеи, метода или инструментария, она предлагается как комплексная поддержка деятельности исполнителей проекта. Однако часто происходит подмена: вместо методологии фактически предлагается набор инструментов, способных в той или иной степени поддерживать некоторые методологии, а о границах применимости не упоминают вовсе. Единственный плюс, который можно в этом усмотреть, — возможность поддержки разных методологий. Но от инструментов до реальной поддержки — долгий путь, гораздо более неопределенный, чем разработка инструментария. И это, к сожалению, обычно замалчивается, что, впрочем, вполне объяснимо стремлением не ограничивать сферу применения предлагаемых средств рамками конкретной методологии.
Это, пожалуй, основная причина затруднений при попытках применения методологий в конкретных условиях. Ситуация только запутывается, когда для такого применения можно задействовать развитую CASE-систему: правила использования ее средств неявно диктуют для конкретного проекта неопределенную методологию, что, как правило, пагубно отражается на качестве работ проекта.
В настоящей лекции мы попытаемся дать некоторые ориентиры для практического применения средств поддержки ведения программных проектов, исходя из примеров популярных и усиленно популяризируемых методологий. Мы называем эти методологии реальными, поскольку имеются сведения об опыте более или менее успешного применения их в реальных проектах. Однако мы не намерены исследовать этот опыт (такое рассмотрение методологий связано с трудностью разделения аспектов, относящихся к конкретным ситуациям, и выделения общностей), а хотим показать принципиальные возможности реализации поддержки деятельности менеджера в условиях различных методологий. Как следует из сказанного выше, в разных подходах эта деятельность существенно различается, а потому для нее требуется и различная поддержка. Единственной точкой соприкосновения, позволяющей говорить об использовании общих понятий, является отношение методологий к жизненному циклу. По этой причине мы ограничиваемся рассмотрением моделей жизненного цикла и отчасти изучением предусмотренных методологией средств поддержки перехода от моделей к работам исполнителей проекта.
Модель RUP
Ранее мы упомянули о том, что сегодня 51% программных разработок применяют CASE-системы, поддерживающие RUP — Rational Unified Processing . Уже одного этого достаточно, чтобы обратить внимание на данный подход и исследовать, за счет чего он обеспечивает ощутимую пользу для практических разработок. Безусловно, достоинством RUP является предлагаемый инструментарий моделирования различных аспектов реализуемого программного обеспечения, и именно этот инструментарий применяется чаще всего. Он привлекает разработчиков выразительностью, поддержкой согласованного использования систем моделей, связываемых общей системой понятий.
В рамках данного курса мы акцентируем внимание на возможности поддержки деятельности менеджера проекта в RUP. Для этого рассматривается модель жизненного цикла как основы методических подходов, которые могут развиваться на базе RUP.
RUP претендует на роль универсальной основы любых программных разработок по единой ("рациональной") схеме. Поэтому естественно, что авторы предлагают общую модель жизненного цикла, которая будет пригодна для всех "рационально" развивающихся проектов. В соответствии с ориентацией преимущественно на стратегию итеративного развития модель должна поддерживать ведение итеративных программных проектов, этапы, выполняемые в ходе итерации, и производственные функции.
Модель задается в виде матрицы интенсивностей функций, выполняемых на этапах (фазах), которые проецируются на итерации (. Авторы CASE-систем, поддерживающих RUP, неизменно подчеркивают иллюстративный стиль изображения интенсивностей. Для каждой итерации можно указать, в какой фазе она находится в данный момент (см. серый овал на рисунке), а также какая рассматривается функция (см. жирную точку и стрелку, ведущую к очередной фазе).
За рамками модели остаются способы, с помощью которых можно было бы переходить к функциям от фаз жизненного цикла. Моделью не конкретизируются виды работ на этапах — это остается в описательной части документа, представляющего процесс разработки. Время также довольно условно: рассмотрение отдельной функции дает представление о горизонтальном развитии событий (переходов от фазы к фазе), но о возможности совместного выполнения некоторых производственных функций речь не идет (быть может, поэтому функции рассматриваются крупным планом, а схемы модели, иллюстрирующие описание RUP, меняются при обсуждении разных аспектов).
Модель выглядит как универсальная схема: с точностью до наименований она отражает то, что включается в любое производство программного обеспечения. Однако она не приспособлена к включению в схему дополнительных этапов и функций, отражающих специфику конкретного процесса или коллектива разработчиков. Это нарушило бы фиксированную связь между жизненным циклом по RUP с моделями уровня проектирования, которым в обсуждаемом подходе уделено особое внимание.
В качестве примера рассмотрим следующую ситуацию. Представим, что в проекте для выбора некоторого решения целесообразно провести программный эксперимент. Эта потребность появляется при выполнении итерации, предполагающей реализацию требования, для которого можно предложить различные решения. Какие функции для этого эксперимента нужно выполнять, мы в состоянии сформулировать. Также понятно, что необходимые работы следует рассматривать как аналитическое исследование. Но решить, как эти работы должны соотноситься с другими работами итерации, пользуясь схемой жизненного цикла RUP, мы не в состоянии. Единственное, что может предложить схема, это вложенная в фазу Анализ и конструирование деятельность, другие варианты просто не получится изобразить.
Причина затруднений вполне понятна: дополнения, о которых мы говорим, реально приводят к новым операционным маршрутам, выполняемым разработчиками проекта (см. лекцию 4), а вынесение их на уровень модели жизненного цикла привело бы к такой конкретизации модели, которая разрушает универсальность. Как следствие, когда нужен отход от универсальности, в проекте приходится компенсировать это специальными комментариями, разъясняющими, какие соглашения о выполнении новых функций принимаются для данного проекта, как они встраиваются в "рациональный унифицированный процесс".
Существенным препятствием для новых операционных маршрутов является то, что не определен регламент применения для них существующих инструментов и методов работы с ними. В RUP представлена масса детально проработанных операционных маршрутов, но связываются они не с деятельностями пользователя, а с конкретными инструментами (используемыми преимущественно для моделирования), допускающими различное применение. Средства моделирования являются элементами языка UML (если угодно — его операционными конструкциями), а не инструментами фиксированной методологии. Такую методологию всегда нужно разрабатывать специально. Выход из положения, предлагаемый авторами RUP, — множество стандартных ситуаций, в которых можно воспользоваться предлагаемыми средствами. Но, к сожалению, на этом пути сложно выстраивать регламенты ситуаций использования инструментов (одна и та же ситуация для одной методологии может быть правомерной, а для другой — нет). И уж совсем не получится организовать контроль связей между объектами, с которыми работают разные инструменты (то, что один и тот же объект используется в разных моделях, установить достаточно просто, но нет возможности проверить нарушение предписания задействовать в разных моделях один и тот же объект).
Таким образом, стремление RUP к универсальности привело к необходимости использования лишь иллюстративной модели жизненного цикла, что, в свою очередь, привело к появлению инструментов и методов их применения, не связанных с моделью жизненного цикла, адекватной проекту. В результате все эти средства в какой бы то ни было CASE-системе, ориентированной на RUP, будут лишь коллекцией, а не комплексом поддержки процессов конкретных методологий. Это, однако, не означает отрицание инструментов CASE-систем RUP, которые оказываются очень полезными для реализации различных методологических подходов, чем во многом и объясняется их популярность.

Модель процессов MSF
Предложение Microsoft Solutions Framework, касающееся жизненного цикла , исходит из идеи механического "скрещивания" каскадной модели MSF (мы ее подробно обсуждали в лекции 7) и самой примитивной спиралевидной модели (подобной спирали охвата предметной области — см. лекцию 8). По мнению авторов, модель процессов MSF "объединяет в себе лучшие принципы каскадной и спиральной моделей. Она сохраняет преимущества упорядоченности каскадной модели, не теряя при этом гибкости и творческой ориентации модели спиральной, учитывает необходимость постоянного пересмотра, уточнения и оценки проектных требований, стимулирует активное взаимодействие между проектной группой и заказчиком, который оценивает ход и результаты работы на протяжении всего проекта".
К сожалению, авторы предложения MSF не совсем точны в своих оценках модели. Как и в случае с RUP, в этой модели очевидно стремление к универсальности, которое неизбежно приводит к огрублению ситуации в конкретных случаях и к необходимости словесного дополнения схемы. Недостатки моделей, основанных на раскручивающейся спирали (см. лекцию 10), присущи ей в полной мере: невозможность отслеживания временных соотношений между сроками выполнения работ, трудности дополнения специфичных этапов. К тому же ориентация на всеобщность лишает модель и тех преимуществ, которые демонстрирует, например, модель Боэма, снабженная конкретным механизмом интерпретации.
Если обратиться к процессам, которые отражают модель MSF, т.е. к их отдельному описанию, то становится заметным стремление авторов сделать методологию гибкой. К примеру, вот что они пишут о сотрудничестве с заказчиком: "Вовлечение заказчика в проект является необходимым условием успешности проектов. Модель процессов MSF предоставляет заказчику широкий спектр возможностей для уточнения и модификации проектных требований и установки контрольных точек (вех) для мониторинга работы над проектом. В свою очередь, это требует затрат времени со стороны заказчика и взятия им на себя определенных обязательств". Однако далее говорится о том, что "MSF признает первостепенную важность договорных и юридических отношений между заказчиком, его поставщиками и проектной командой и необходимость управления этими отношениями". (Стоит сопоставить эти высказывания с соответствующим принципом Agile Manifesto — см. лекцию 5.) Только из схемы ни первое, ни второе утверждение извлечь нельзя. И это пример словесного дополнения, к которому приходится прибегать при неудовлетворительном схематическом представлении модели.
Изучение методологии, провозглашаемой MSF, позволяет сделать вывод о том, что ее авторы достаточно тщательно проработали процессы менеджмента, когда основой организации коллектива разработчиков считается проектная группа с рассредоточенными ролями (мы об этом уже говорили в лекции 2). Но опять-таки в модели жизненного цикла это обстоятельство никак не отражено, что вполне объяснимо стремлением к всеобщности. Отсюда следует, что обсуждаемое предложение всегда в конкретных проектах должно адаптироваться. Сделать это проще, чем, к примеру, в случае RUP или жестких схем, которые только и допускает стандарт CMM . Однако до уровня стратегии быстрого развития предложения MSF не доходят и занимают промежуточное положение между жесткими и гибкими методологиями.
Жизненный цикл в методологиях быстрого развития проектов
Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта (см., например, ). Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разработки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой характер, который позволяет менеджеру в большей мере сосредоточиться на руководстве командой, чем на управлении. В результате отслеживание процесса не требует, к примеру, специальных документов о достигнутых результатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претендуют на инструментальность, и в таком ключе их рассматривать не имеет смысла. Тем не менее понятия контрольных точек и контрольных мероприятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным.
Жизненный цикл любой методологии быстрого развития можно описать следующим образом.

  • Начальная фаза. Она выделена, поскольку приходится выполнять работы, которые не являются характерными для основного процесса.
  • Серия максимально коротких итераций, состоящих из шагов:
    • выбор реализуемых требований (в экстремальном программировании — пользовательских историй);
    • реализация только отобранных требований;
    • передача результата для практического использования;
    • короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием).
  • Фаза заключительной оценки разработки проекта.

Реальные быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками (пример того, как это делается в экстремальном программировании , будет рассмотрен ниже).
До последнего времени быстрые процессы было не принято формализовывать настолько, чтобы их можно было предлагать в качестве стандарта. И сегодня не приходится говорить, например, о сертифицировании команды как "правильно" работающей по быстрой методологии, подобном тому, что требует CMM. Тем не менее вопрос о сертификации быстрого процесса приобретает актуальность — складывается своеобразная мода на гибкие методологии, отрицательно сказывающаяся на престиже подхода в целом. Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасения, что в результате быстрые подходы станут формализованными до такой степени, что их нельзя уже будет называть гибкими. Эта проблема отмечалась во многих докладах на недавней конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003 .
Тем не менее сегодня уже появилась компания, выполняющая проекты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000 , свидетельствующий об определенных гарантиях качества организации проектной деятельности и получаемых результатов. Это произошло весной 2003 года по прошествии примерно года с момента подачи заявки на сертификацию . Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и поддерживаемыми стандартом. В остальном процедура сертификации не нарушила процессы производства программ в компании. Не потребовалось никакой настройки процесса, доведения его до требований стандарта. Не претерпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования (см. лекцию 2), признана соответствующей требованиям качества и т.д..
В последующих разделах мы конкретизируем общую для быстрых методологий схему на примере двух характерных подходов к разработке программных систем.

Модель жизненного цикла экстремального программирования
В монографии по экстремальному программированию Бек жизненный цикл экстремального программирования описывает, не прибегая к схемам. Словесно описывая деятельности разработчиков, он дает картину процесса, не требующую иллюстраций. Тем не менее построить такую схему несложно, и это полезно сделать хотя бы для сопоставления моделей (Бек говорит не о моделях, а об идеальном проекте). Мы приводим модель жизненного цикла проекта в экстремальном программировании в представлении, которое исходит из гантеровских изобразительных средств .
Из схемы видно, что начальная фаза развития проекта включает в себя некоторое число итераций без выпуска релиза. Это период, когда просто невозможно предоставить систему пользователям. В качестве его задач указывается изучение применяемых инструментов, постановка экспериментов с целью определения и последующего построения стартового варианта архитектурного скелета системы, а также, возможно, освоение методик экстремального программирования командой. Бек выделяет первое внедрение системы в эксплуатацию как особое событие, которое стоит отметить праздничными мероприятиями. В экстремальном программировании подобные мероприятия и другие меры поощрительного воздействия на коллектив занимают существенное место среди менеджерских задач.
Серия итераций — это стационарный период развития проекта, в котором появляется деятельность, связанная с обслуживанием и поддержкой. В отличие от жестких методологий, при экстремальном программировании эти задачи не становятся дополнительной нагрузкой для разработчиков, поскольку методика взаимодействия с заказчиком обеспечивает нужное, актуальное для пользователей развитие работ.
Как только в проекте исчерпывается постоянно пополняемый пул заказываемых для реализации пользовательских историй, исчезает стимул для развития проекта. Эту ситуацию Бек называет смертью проекта. Со смертью проекта использование построенной системы не прекращается. Напротив, отсутствие новых требований к ней свидетельствует о том, что пользовательские нужды обеспечены адекватной поддержкой. Но возможны и другие, менее оптимистичные причины для "смерти". Это либо переход пользователей к применению конкурирующей разработки, которая оказалась более подходящей, либо невозможность в разумные сроки реализовать необходимые возможности системы (по сути дела, обе причины означают одно и то же). Во всех случаях смерть проекта надо достойно встретить. Соответствующие работы указаны на схеме.
В модели отмечены контрольные точки, связанные с событиями проекта. Смысл их вполне понятен, а конкретизация соответствующих мероприятий привела бы к пересказу подхода в своей интерпретации. По этой же причине мы не станем обсуждать производственные функции и систему деятельностей, которую можно восстановить из описания методологии экстремального программирования.
Отметим, что с точностью до 12 методик, которые объявляются Беком как суть подхода при изучении этой методологии вполне применимы общие понятия, рассмотренные раньше. Так, деятельность менеджера экстремального проекта в полной мере иллюстрирует следование принципу выяснения отклонений и корректировки траектории.
Методология экстремального программирования является характерным примером использования стратегии сужения задачи проекта за счет итеративного наращивания возможностей. Обратившись к представленной ранее схеме итеративного наращивания , можно заметить, что в данном подходе конкретизировано движение требований таким образом, чтобы получить ясные и точные критерии их отбора для реализации с помощью апелляции к заказчику. Из этого следуют и границы применимости подхода: когда заказчик плохо представляет, что фактически нужно для поддержки деятельности пользователя, а для аналитического исследования проблем автоматизируемой деятельности возможности нет, экстремальное программирование будет давать сбои. Если воспользоваться метафорой вождения автомобиля, то можно сказать, что этот подход хорошо работает в условиях шоссе, но не на бездорожье.

Адаптивная разработка (ASD) по Хайсмиту
Следующая иллюстрация относится к области быстрых методологий, в которой заостряется внимание на необходимости адаптивной разработки (см. лекцию 7). Хайсмит, автор этого подхода, в течение многих лет работал с предсказуемыми методологиями. Он занимался их разработкой, внедрял их, учил ими пользоваться и в конце концов пришел к выводу, что они глубоко ошибочны в условиях современного бизнеса. В вышедшей недавно книге он указывает на адаптивную природу новых методологий, обращая особое внимание на использование идей из области сложных адаптивных систем (обычно их называют теорией хаоса). В книге нет подробного описания методик, подобных тем, что провозглашаются в экстремальном программировании и делают этот подход законченной методологией, однако в ней закладывается фундаментальная теоретическая основа адаптивных разработок. Хайсмит показывает, почему эти методологии так важны и к каким последствиям приводит их использование на более глубоком организационном и руководящем уровне.
Основу ASD составляют три нелинейные, перекрывающие друг друга фазы: обдумывание, сотрудничество и обучение, относящиеся к каждому периоду разработки, который завершается выпуском релиза . Подчеркивается, что планирование в окружении, которое требует адаптивности, является парадоксом, поскольку результаты в этом случае всегда непредсказуемы. При обычном планировании отклонения от плана являются ошибками, которые нужно исправлять. В адаптивных разработках отклонения ведут к решениям, которые объективно обусловлены, а потому их следует считать правильными.
Неопределенность в столь непредсказуемой среде преодолевается за счет активного сотрудничества разработчиков. При этом внимание руководства направлено не столько на объяснения, что именно нужно делать, сколько на обеспечение коммуникации, при которой разработчики сами находят ответы на возникающие вопросы. Отсюда следует повышенное внимание к обучению, значение которого в предсказуемых методологиях часто занижается: все расписывается заранее, так что потом остается только следовать плану. Хайсмит пишет , что "ѕ в адаптивном окружении обучения не избежать всем участникам проекта — и разработчикам, и их заказчикам, поскольку и те и другие в процессе работы должны пересматривать собственные обязательства, а также использовать итоги каждого цикла разработки для того, чтобы подготовиться к следующему".
Из этого положения делается вывод, относящийся к жизненному циклу адаптивных разработок "Основное, наиболее действенное и первостепенное достоинство жизненного цикла ASD заключается в том, что этот процесс заставляет отказаться от интеллектуальных построений, которые являются источником самообмана. Он вынуждает оценивать собственные способности более реалистично".
Из приведенной схемы не ясно, как предлагается организовывать процесс, как компенсировать потенциально "расползающуюся" разработку, когда по мере развития она обрастает все новыми возможностями, обусловленными практическими нуждами, но без общей (в других подходах сказали бы — предсказуемой) архитектурной базы. Оставив все это в стороне, т.е. относя подобные вопросы к конкретной методологии, автор ASD освещает сложные моменты адаптивных разработок, в частности вопросы обеспечения сотрудничества и обучения во время реализации проекта. И в этом ценность работы Хайсмита, поскольку полученные результаты применимы в самых разных случаях.
Таким образом, можно сказать, что ASD — это не готовая методология, а базовая концепция для различных адаптивных разработок. Схема жизненного цикла не является сдерживающим фактором построения конкретных методологий, которые вполне могут следовать самым разнообразным стратегиям, включать в себя те или иные методики. В этом отношении подход Хайсмита сближается еще с одной "серийной" методологией быстрого развития, предложенной А. Коуберном. Речь идет о семействе методологий Crystal . Коуберн называет это семейством, так как убежден, что разным проектам нужны разные методологии. Он вводит следующую градацию проектов: по одной оси откладывается количество занятых в проекте людей, по другой — критичность ошибок. Каждая из методологий семейства предназначена для определенной ячейки получившейся сетки. Таким образом, проект, в котором занято 40 человек, и на котором компания может позволить себе потерять некоторую сумму, будет работать по другой методологии, нежели проект для шести разработчиков, от которого зависит существование компании.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика