Модель RUP

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

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

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

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

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

Ранее мы упомянули о том, что сегодня 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, которые оказываются очень полезными для реализации различных методологических подходов, чем во многом и объясняется их популярность.

Модель процессов MSF

Предложение Microsoft Solutions Framework, касающееся жизненно­го цикла [44], исходит из идеи механического «скрещивания» каскадной модели MSF (мы ее подробно обсуждали в лекции 7) и самой примитив­ной спиралевидной модели (подобной спирали охвата предметной облас­ти — см. лекцию 8). По мнению авторов, модель процессов MSF (см. рис 11.2) «объединяет в себе лучшие принципы каскадной и спиральной мо­делей. Она сохраняет преимущества упорядоченности каскадной модели, не теряя при этом гибкости и творческой ориентации модели спираль­ной, учитывает необходимость постоянного пересмотра, уточнения и оценки проектных требований, стимулирует активное взаимодействие между проектной группой и заказчиком, который оценивает ход и резуль­таты работы на протяжении всего проекта».

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

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

Если обратиться к процессам, которые отражают модель MSF, т.е. к их отдельному описанию, то становится заметным стремление авторов сделать методологию гибкой. К примеру, вот что они пишут о сотрудни­честве с заказчиком: «Вовлечение заказчика в проект является необходи­мым условием успешности проектов. Модель процессов MSF предостав­ляет заказчику широкий спектр возможностей для уточнения и модифи­кации проектных требований и установки контрольных точек (вех) для мониторинга работы над проектом. В свою очередь, это требует затрат времени со стороны заказчика и взятия им на себя определенных обяза­тельств». Однако далее говорится о том, что «MSF признает первостепен­ную важность договорных и юридических отношений между заказчиком, его поставщиками и проектной командой и необходимость управления этими отношениями». (Стоит сопоставить эти высказывания с соответст­вующим принципом Agile Manifesto [31] — см. лекцию 5.) Только из схе­мы ни первое, ни второе утверждение извлечь нельзя. И это пример сло­весного дополнения, к которому приходится прибегать при неудовлетво­рительном схематическом представлении модели.

Изучение методологии, провозглашаемой MSF, позволяет сделать вывод о том, что ее авторы достаточно тщательно проработали процессы менеджмента, когда основой организации коллектива разработчиков считается проектная группа с рассредоточенными ролями (мы об этом уже говорили в лекции 2). Но опять-таки в модели жизненного цикла это обстоятельство никак не отражено, что вполне объяснимо стремлением к всеобщности. Отсюда следует, что обсуждаемое предложение всегда в конкретных проектах должно адаптироваться. Сделать это проще, чем, к примеру, в случае RUP или жестких схем, которые только и допускает стандарт СММ [18]. Однако до уровня стратегии быстрого развития пред­ложения MSF не доходят и занимают промежуточное положение между жесткими и гибкими методологиями.

Жизненный цикл в методологиях быстрого развития проектов

Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта (см., например, [3]). Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разра­ботки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой харак­тер, который позволяет менеджеру в большей мере сосредоточиться на ру­ководстве командой, чем на управлении. В результате отслеживание про­цесса не требует, к примеру, специальных документов о достигнутых ре­зультатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претенду­ют на инструментальность, и в таком ключе их рассматривать не имеет смысла. Тем не менее понятия контрольных точек и контрольных меро­приятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным.

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

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

• Серия максимально коротких итерации, состоящих из шагов:

—выбор реализуемых требований (в экстремальном программиро­вании — пользовательских историй);

—реализация только отобранных требований;

—передача результата для практического использования;

—короткий период оценки достигнутого (в зависимости от объема
работ периода его можно назвать этапом или контрольным ме­роприятием).

• Фаза заключительной оценки разработки проекта.

Реальные быстрые методологии конкретизируют эту схему, допол­няют ее теми или иными методиками (пример того, как это делается в экстремальном программировании [3], будет рассмотрен ниже).

До последнего времени быстрые процессы было не принято формализовывать настолько, чтобы их можно было предлагать в качестве стан­дарта. И сегодня не приходится говорить, например, о сертифицирова­нии команды как «правильно» работающей по быстрой методологии, по­добном тому, что требует СММ. Тем не менее вопрос о сертификации бы­строго процесса приобретает актуальность — складывается своеобразная мода на гибкие методологии, отрицательно сказывающаяся на престиже подхода в целом. Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасе­ния, что в результате быстрые подходы станут формализованными до та­кой степени, что их нельзя уже будет называть гибкими. Эта проблема от­мечалась во многих докладах на недавней конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003 [37].

Тем не менее сегодня уже появилась компания, выполняющая проек­ты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000 [39], свидетельствующий об определенных гарантиях качества организации про­ектной деятельности и получаемых результатов. Это произошло весной 2003 года по прошествии примерно года с момента подачи заявки на сертифика­цию [51]. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и под­держиваемыми стандартом. В остальном процедура сертификации не нару­шила процессы производства программ в компании. Не потребовалось ни­какой настройки процесса, доведения его до требований стандарта. Не пре­терпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования (см. лек­цию 2), признана соответствующей требованиям качества и т.д.*.

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

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

В монографии по экстремальному программированию [3] Бек жиз­ненный цикл экстремального программирования описывает, не прибегая к схемам. Словесно описывая деятельности разработчиков, он дает кар­тину процесса, не требующую иллюстраций. Тем не менее построить та­кую схему несложно, и это полезно сделать хотя бы для сопоставления моделей (Бек говорит не о моделях, а об идеальном проекте). Мы приво­дим модель жизненного цикла проекта в экстремальном программирова­нии в представлении, которое исходит из гантеровских изобразительных средств (см. рис. 11.3).

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

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

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

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

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

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

Отметим, что с точностью до 12 методик, которые объявляются Беком как суть подхода, [3] при изучении этой методологии вполне применимы общие понятия, рассмотренные раньше. Так, деятельность менеджера экс­тремального проекта в полной мере иллюстрирует следование принципу выяснения отклонений и корректировки траектории (см. лекцию 5).

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

Адаптивная разработка (ASD) по Хайсмиту

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

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

Неопределенность в столь непредсказуемой среде преодолевается за счет активного сотрудничества разработчиков. При этом внимание руко­водства направлено не столько на объяснения, что именно нужно делать, сколько на обеспечение коммуникации, при которой разработчики сами находят ответы на возникающие вопросы. Отсюда следует повышенное внимание к обучению, значение которого в предсказуемых методологиях часто занижается: все расписывается заранее, так что потом остается толь­ко следовать плану. Хайсмит пишет [41], что «... в адаптивном окружении обучения не избежать всем участникам проекта — и разработчикам, и их заказчикам, поскольку и те и другие в процессе работы должны пересмат­ривать собственные обязательства, а также использовать итоги каждого цикла разработки для того, чтобы подготовиться к следующему».

Из этого положения делается вывод, относящийся к жизненному циклу адаптивных разработок [41]: «Основное, наиболее действенное и первостепенное достоинство жизненного цикла ASD заключается в том, что этот процесс заставляет отказаться от интеллектуальных построений, которые являются источником самообмана. Он вынуждает оценивать собственные способности более реалистично».

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

Таким образом, можно сказать, что ASP — это не готовая методоло­гия, а базовая концепция для различных адаптивных разработок. Схема жизненного цикла не является сдерживавшим фактором построения конкретных методологий, которые вполне могут следовать самым разно­образным стратегиям, включать в себя те или иные методики. В этом от­ношении подход Хайсмита сближается еще с одной «серийной» методо­логией быстрого развития, предложенной А. Коуберном. Речь идет о се­мействе методологий Crystal [36]. Коуберн называет это семейством, так как убежден, что разным проектам нужны разные методологии. Он вво­дит следующую градацию проектов: по одной оси откладывается количе­ство занятых в проекте людей, по другой — критичность ошибок. Каждая из методологий семейства предназначена длЯ определенной ячейки полу­чившейся сетки. Таким образом, проект, в котором занято 40 человек, и на котором компания может позволить себе потерять некоторую сумму, будет работать по другой методологии, нежели проект для шести разра­ботчиков, от которого зависит существование компании.

Вариант 1

1. RUP провозглашается унифицированной основой организации и ведения любых рационально устроенных про­граммных проектов. Так ли это?

□ нет, так как это в принципе невозможно

□ да, так как в RUP предлагается полный комплект инструмен­тов, пригодный для поддержки всех видов проектной деятель­ности

□ да, так как RUP всегда дает возможность воспользоваться
предлагаемой авторами методикой разработки проектов, под­держанной инструментально

□ нет, так как предлагаемый в RUP комплект средств и инстру­ментов не объединен системой деятельностей, которая и со­ставляет методологию (методику) ведения проектов

2. Как сторонники методологий быстрого развития относятся к сертификации компаний, в которых процесс произ­водства программного обеспечения основывается на этих методологиях?

□ поддерживают, так как это поможет построить объединенную
универсальную методологию быстрого развития

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

□ поддерживают, так как это будет способствовать росту прести­жа данного методологического направления

□ индифферентно, так как этот вопрос решается на уровне конкретной компании

□ отрицательно, так как не может быть единого стандарта для
всех быстрых методологий

3. Какие методические стратегии и приемы используются
менеджером для организации проектной деятельности при
экстремальном программировании?

□ определение этапов проекта

□ сужение проектной задачи

□ определение отклонений траектории проектной деятельности
и корректировка

□ распределение ресурсов и ответственности

□ выполнение измерений процесса реализации проекта

Вариант 2

1. Модель жизненного цикла RUP задается в виде:

□ последовательности итераций, для которых задано разбиение
процесса на этапы (фазы)

□ схемы переходов от итерации к итерации, включающей в себя
задание производственных функций

□ матрицы интенсивностей функций, выполняемых на этапах
(фазах), которые проецируются на итерации

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

□ описания бизнес-процессов производства программного обес­печения

2. Какие фазы и этапы можно указать в жизненном цикле
при любой методологии быстрого развития?

□ начальная фаза, серия итераций, состоящая из шагов выбора
требований для реализации, реализации требований, внедре­ния и оценки, фаза заключительной оценки

□ анализ требований, спецификация разрабатываемого про­граммного обеспечения, конструирование архитектуры, реа­лизация, отладка, выпуск продукции

□ обдумывание, сотрудничество, обучение

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

3. Адаптивная разработка по Хайсмиту — это:

□ методология программирования, предлагающая для использо­вания полный комплект средств, инструментов и методов, по­зволяющих эффективно выполнять проекты в условиях неоп­ределенности их развития

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

□ проект, менеджер которого не делает никаких предположений
о будущем развитии

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

Вариант 3

1. Операционные маршруты в RUP определены для:

□ деятельностей ролей разработчиков

□ выполнения производственных функций

□ предлагаемых инструментов

□ в описании процесса — для шаблонных действий разработчи­ков в распознаваемых ситуациях, в описании инструментов —
для того, чтобы знать, как ими пользоваться

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

2. Задачи начальной фазы методологии экстремального
программирования:

□ построение единой концепции проекта

□ создание условий для выполнения проекта в рамках методоло­гии экстремального программирования

Q построение и внедрение первого релиза программной системы О исследование предметной области, разработка архитектуры и подготовка к первой итерации

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

3. Основой адаптивной разработки по Хайсмиту является:

□ планирование этапов разработки, каждый из которых адапти­рует проект к определенной части требований

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

□ распределение решаемых проблем по этапам разработки

□ три нелинейные, перекрывающие друг друга фазы обдумыва­ния, сотрудничества и обучения

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

Дата добавления: 2014-01-06