Лекция 5. Методологические стратегии

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

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

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

Проект в целом можно представить в виде конуса операционных маршру­тов, центр которого соответствует замыслу, а основание — множеству всех ва­риантов завершения проекта. На основании конуса выделяется целевая об­ласть — варианты завершения проекта, соответствующие его целям. Траекто­рии, которые ведут в целевую область, являются допустимыми (см. рис. 5.1).

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

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

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

Определение этапов проекта: последовательное развитие проекта

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

задачи каждого этапа характеризуется:

• субъектом-исполнителем;

• сроками, когда должны быть решены задачи;

• выделенными ресурсами;

• средствами, инструментами и методами решения задач;

• контрольными мероприятиями, позволяющими удостовериться, что задачи этапа решены.

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

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

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

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

Стратегия определения этапов получила название последовательного развития проектов*. Это исторически первая стратегия, которой придер­живались при разработке программных проектов, а потому для нее сущест­вует много методик и их вариантов, но все они укладываются в схему, изо­браженную на рис. 5.3. Из схемы видно, что при последовательном разви­тии сокращение объема конуса операционных маршрутов достигается за счет разбиения его на ряд более мелких конусов, соответствующих этапам.

Сужение текущей задачи проекта: итеративное наращивание возможностей

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

* Слово «последовательное» ~ один из возможных переводов английского «waterfall», в котором отражено то, что к действию, выполненному однажды, не возвращаются. Другой, быть мо­жет, более точный перевод — «каскадное» (английское «cascade» переводится, в частности, как. «последовательное»). Буквальный перевод «waterfall» как «водопадное» мы считаем неприе­млемым из-за четкой ассоциации в русском языке слова «вода» с чем-то пустопорожним, бессо­держательным. Как будет видно из дальнейшего изложения, мы различаем понятия «последова­тельное» и «каскадное», рассматривая последнее как частный случай последовательного разви­тия проектов. В качестве варианта перевода слова «последовательное» укажем на использова­ние термина «линейные методологии» [15].

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

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

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

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

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

Определяя стратегии последовательного и итеративного развития проектов, мы исходили из того, что контроль деятельности проекта — за­дача, требующая специальных организационных подходов. Общей целью является превращение создания программного продукта в упорядочен­ный процесс, в рамках которого развитие проекта можно сделать более прогнозируемым и эффективным. Для этого обычно создается детальное описание процесса разработки системы, особое место в котором занима­ет планирование. Иначе говоря, создается метод, с помощью которого предполагается конструировать систему. Удачные методы обобщаются, в результате опыт их применения превращается в методику, или, как сей­час принято говорить, методологию*. Нередко при таком формировании методики-методологии фиксируются частные и случайные решения, ока­завшиеся полезными из-за специфики удачных проектов. Наряду со всем полезным эти решения объявляются обязательными, стандартными, их вынуждены применять и тогда, когда исходные предпосылки утрачены. Чтобы следовать таким методологиям, приходится выполнять множество различных предписаний, что замедляет темп основных программистских работ. Поэтому их называют тяжеловесными, жесткими или, согласно [41], монументальными.

* В программировании наблюдается постоянная «возгонка» терминов: там, где должно быть орудие, говорят об инструменте, вместо слова «инструмент» употребляется «метод», вместо метода — методика, а методику заменяют методологией [16]. К сожалению, мы вынуждены пользоваться термином «методология», привычным в данной области настолько, что иное сло­воупотребление будет непонятным.

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

В настоящее время разработаны стандарты зрелости процессов раз­работки программного обеспечения в организациях. Среди них наиболее развитым является предложение Института программной инженерии при Университете Карнеги—Меллона — так называемая модель SW-CMM (Capability Maturity Model for Software) [18]. Эту модель можно считать об­щепринятой, поскольку на нее чаще всего ориентируются заказчики, в частности из Министерства обороны США, предлагая проекты только тем организациям, которые сертифицированы на уровнях зрелости 4 и 5 (мы еще будем обсуждать эту модель). Как замечено в [47], модель СММ была сформирована при существенном влиянии практики военных зака­зов с их жесткой процедурой контроля и отчетности. Предложения СММ для определения зрелости организации опираются на то, какие процеду­ры управления программными проектами, отслеживания их развития и другие менеджерские методы приняты в качестве фирменного стандарта. Методологии программирования, построенные на базе этих предложе­ний, часто рассматривают как эталон жесткости.

В противовес жестким методологиям в последнее время сформиро­вался компромиссный подход, методологии которого объединены общим термином agile development. На русский язык его переводят как быстрое развитие, гибкие методологии (см. перевод статьи М. Фаулера [24]) и даже «шустрые технологии» (см. [26])*. В новом подходе пытаются предоставить возможность облегченной организованной работы программистских кол­лективов, когда перегруженность стандартизованного процесса препятст­вует эффективности. Они претендуют на то, что их применение возможно даже когда не удается достаточно точно представить проект при его заро­ждении, т.е. в довольно типичной ситуации неопределенности реальной пользовательской потребности. В этих случаях предлагается привлечение

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

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

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

Охарактеризовать все методологии быстрого развития по отдельно­сти не представляется возможным — слишком различны их исходные принципы, слишком зависимы они от специфики коллективов, занима­ющихся разработками программного обеспечения, от зачастую стихийно складывающихся предпочтений, привычек. На стратегическом уровне их действительно объединяет так называемый Agile Manifesto [31], принятый энтузиастами в феврале 2001 года в местечке Сноуберд (США), который сводится к четырем постулатам:

• индивидуумы и их взаимодействие важнее процессов и инструментов;

• работоспособное программное обеспечение важнее обширной до­кументации;

• сотрудничество с заказчиком важнее заключения контракта;

• готовность к изменениям важнее следования плану.

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

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

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

В отличие от традиционных подходов быстрые методологии ориен­тируются на то, что деятельность по производству программного обеспе­чения по сути своей является преимущественно креативной, т.е. такой, в которой от разработчиков требуется не только распознавание ситуаций и применение в них известных методов, но и конструирование новых мето­дов действия.* А это другой, более высокий уровень знаний и умений (см. [16]). Как отмечает Фаулер [24], процесс разработки программного обес­печения, постоянно адаптирующийся к меняющимся требованиям поль­зователей, принципиально непредсказуем. Это качество обуславливает креативность деятельности не только в начале проекта, но и в течение все­го его развития. Непредсказуемость и креативность разработки программ­ного обеспечения указывает на то, что готовых рецептов на все случаи жизни просто не хватит, а потому среди элементов деятельности должны иметь больший удельный вес средства и инструменты, нежели методы.**

В табл. 5.1 представлено сопоставление жесткой и быстрой стра­тегий в методологиях программирования. Из этого сопоставления вид-

* Слово «преимущественно» в обоих случаях употреблено по той причине, что в реальности лю­бой субъект-исполнитель проекта выполняет целый спектр деятельностей, одни из которых оказываются императивными (так предписано их выполнять), а другие — креативными (вме­сто предписаний для их выполнения используются указания ситуаций и другие приемы высоких уровней знаний и умений).

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

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

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

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

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

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

процесса и результатов, контрольные мероприятия и многое другое.* Но, не­смотря на появление разнообразных методик, средств и инструментов под­держки управления, которые вынуждены применять менеджеры (что как раз и стало предметом критики сторонников облегченных методологий), особо­го успеха добиться не удалось. Причина тому - и уже не раз упоминавшаяся изменчивость требований, и свойственная природе человека склонность до­пускать ошибки на всех уровнях работы. Ограждать ситуации от возможных ошибок, помогать их поиску, использовать средства автоматизации, способ­ные ликвидировать многие рутинные операции, мы научились, а потому можно говорить о некоторой технологизации. Но от этого креативный про­цесс программирования не стал подобен тому, что демонстрирует материаль­ное производство или, к примеру, бухгалтерский учет.

Представленное определение технологии достаточно конструктивно: в любой ситуации, когда элементы деятельности определены, можно зада­вать вполне конкретные вопросы, позволяющие выяснить технологич­ность. К сожалению, проверка области разработки программного обеспе­чения на практике свидетельствует, что технологичность ее деятельностей характеризуется фрагментарностью: отдельные виды работ доведены даже до уровня автоматизации, но комплексной технологии, охватывающей весь процесс, не предлагает никто. Скорее всего, сложность этого произ­водства, а также объективная непредсказуемость его (о чем красноречиво пишет, например, Фаулер [24], с чем согласны многие непредвзятые иссле­дователи — см., например, [15]) не позволяют говорить об универсальном технологическом процессе на все случаи жизни. Претензии RUP [30] — не в счет, и в свое время мы еще вернемся к этому вопросу.

* Отметим вскользь, что разработка методологий (читай — методов, методик) программиро­вания неоднозначна, что свидетельствует о творческом и креативном характере этой дея­тельности.

Вариант 1

1. Конус операционных маршрутов проектной деятельности — это:

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

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

• наглядное представление траекторий процесса развития про­екта, в котором центр конуса соответствует замыслу, а основа­ние — множеству всех вариантов завершения проекта ■

• наглядное представление траекторий процесса развития про­екта, в котором центр конуса соответствует замыслу, а основа­ние — множеству всех вариантов завершения проекта, соответствующих его целям

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

2. Когда методология может оказаться жесткой?

□ когда она строится без учета того, что программные проекты объективно непредсказуемы

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

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

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

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

Детерминизм, который предписывается для технологич­ной деятельности,— это:

• деятельность, для выполнения которой не требуется высокая квалификация исполнителей

• деятельность, имеющая приказной характер методов

• связка методов и целей, которой подчинены заданные средст­ва и инструменты

• возможность полной автоматизации для всех распознаваемых ситуаций

• производственные функции не имеют отношения к системе деятельностей проекта

Вариант 2

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

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

• отслеживать выход траектории из области допустимых марш­рутов и своевременно воздействовать на нее для возвращения в эту область

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

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

• обеспечивать гарантии достижения целей этапов за счет мониторинга процесса проектных деятельностей

2. Укажите высказывания, которые не разграничивают жест­ кие и быстрые методологические стратегии:

П ориентация на предсказуемые или на непредсказуемые про­цессы разработки программного обеспечения

• использование последовательного или итеративного развития разработки проекта

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

• заказчик в ходе разработки выполняет только контрольные функции или участвует в выборе пути развития проекта

• процесс разработки учитывает или не учитывает человеческий фактор

3. Как можно пытаться ликвидировать недетерминизм дея­тельности?

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

• за счет повышения квалификации сотрудников

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

• за счет пересмотра целей деятельности

недетерминизм деятельности ликвидировать невозможно

Вариант 3

Автокоррекция — это:

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

• условия, которые без внешнего влияния не позволяют испол­нителю какой-либо деятельности допускать ситуации отклоне­ния траектории от области допустимости

• исправление траектории деятельности исполнителем с помо­щью доступных ему средств и инструментов

• организация деятельности таким образом, что ее траектория никогда не будет отклоняться от области допустимости

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

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

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

• средства и инструменты используются при неукоснительном следовании методам

• возможно повторение процесса выполнения деятельности при потреблении того же ресурса с тем же результатом

• субъект-исполнитель удовлетворяет заданным квалификаци­онным требованиям

• дополнительное повышение качества может быть достигнуто при повышении квалификации субъекта-исполнителя

. Agile Manifesto — это документ, который фиксирует:

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

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

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

• противопоставление жестких и гибких методологий

• необходимые и достаточные условия, чтобы методологию можно было считать гибкой