Рефакторинг архитектуры

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

Одним из наиболее успешных подходов к изменению существующего программного обеспечения является рефакторинг – подход, основанный на систематических трансформациях исходного кода. Рефакторинг – это изменение во внутренней структуре ПО, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения. В привычном понимании разработки ПО сначала создается дизайн системы, а потом пишется ее код. Со временем код модифицируется, и целостность системы, соответствие ее структуры изначально созданному дизайну постепенно ухудшается. Дальнейшее развитие системы постепенно сползает от направленной, проектируемой деятельности к хакерству. Рефакторинг представляет собой противоположную практику. С его помощью можно взять плохой, хаотический проект и переделать его в хорошо спроектированный код. Каждый шаг этого процесса чрезвычайно прост. Например, шагом может стать перемещение поля или метода из одного класса в другой, расщепление класса и т.д. Однако суммарный эффект таких небольших изменений оказывается кумулятивным и может радикально улучшить проект. Процесс рефакторинга является прямой противоположностью постепенной деградации кода системы [2].

При документации и каталогизации методов рефакторинга принято использовать полуформальную нотацию, в которой каждый из методов описан так называемым паттерном. Любой паттерн описывает и именует типовую задачу, которая постоянно возникает в работе, а также принцип ее решения, причем таким образом, что это решение можно использовать потом снова и снова. Паттерн именует, абстрагирует и идентифицирует ключевые аспекты структуры общего решения [6]. Помимо прочего, паттерны формируют словарь решений для данной проблемной области и позволяют двум специалистам в этой области именовать типовые решения и понимать друг друга, не объясняя каждый раз суть самих решений.

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

Архитектура ПО и ее рефакторинг

В настоящее время не существует общепринятого определения термина “архитектура программного обеспечения”. В то же время, существует большое количество различных определений этого понятия, имеющих во многом схожий смысл. В качестве примера можно привести следующее определение: архитектура программного обеспечения - это первичная организация системы, сформированная ее компонентами, отношениями между компонентами и внешней средой системы, а также принципами, определяющими дизайн и эволюцию системы [3].

Фазы архитектурного рефакторинга

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

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

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

"Раскопка" архитектуры. Шаги, относящиеся к этой фазе, характеризуются тем, что соответствующие действия, применяемые к модели, не ориентированы на последующее проецирование на программный код.
Они нужны только для понимания и структуризации модели.

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

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

Как представить архитектуру и ее изменения?

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

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

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

Модели программных систем, используемые в KLOCwork Architect (в дальнейшем модели) [4], отдаленно напоминают модели типа сущность-связь (Entity-Relation models). Говоря строго, они относятся к классу контейнерных моделей, подробно рассматриваемых в работе [5]. Основными элементами модели являются следующие элементы:

Архитектурный блок (Architecture Block). Модель KLOCwork Architect состоит из так называемых архитектурных блоков. Архитектурные блоки представляют в модели структурные элементы программной системы, вне зависимости от уровня абстракции, на котором идет моделирование. Архитектурные блоки обладают, по меньшей мере, двумя основными атрибутами: имя и тип.
Имена архитектурных блоков предопределяются именами тех структурных элементов системы, которые они представляют в модели. Типы архитектурных блоков существенно зависят от уровня абстракции, на котором происходит моделирование, и конкретной задачи, в рамках которой проводятся исследование архитектуры. Например, при моделировании систем, построенных в рамках каких-либо компонентных технологий, основным используемым типом архитектурных блоков являются “компоненты”. При моделировании системы сборки ПО основными используемыми типами являются “папки” и “файлы”.

Отношение (Relation). В модели KLOCwork Architect под отношением понимается односторонняя связь между парой архитектурных блоков. Так же, как и архитектурные блоки, отношения могут быть различных типов. В качестве примера можно привести следующие типы отношений:

Инстанциация: A инстанциирует B (блок A – функция, блок B – класс).Доступ к данным: A читает данные из B (блок A – функция, блок B – класс или атрибут класса).

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

Пример модели. В качестве иллюстрации рассмотрим микроскопическую тестовую систему на языке C и модель, автоматически полученную из нее системой Architect. Система имеет следующую структуру:Папка test, содержащая:Файл a.h, содержащий текстvoidФайл a.cpp, содержащий текст#include "a.h"

void a() {

int a = 0; a++; }

Для подобной системы извлеченная автоматически модель будет иметь следующую структуру:

Таблица 1.

Литература:

[1] Research Issues in The Renovation of Legacy Systems, A. van Deursen, P. Klint, C. Verhoef, CWI research report P9902, April 1999

[2] Рефакторинг: Улучшение существующего кода, Мартин Фаулер, Символ, Санкт-Петербург, 2003

[3] Recommended Practice for Architectural Description of Software-Intensive Systems, ANSI/IEEE Std 1471-2000

[4] Insight: reverse engineer case tool, N. Rajala, D. Campara, N. Mansurov, IEEE Computer Society Press, 1999, Los Alamitos, CA, USA Pages: 630 – 633

[5] Managed Achitecture of Existing Codeas a Practical Transition towards MDA, N. Mansurov, D. Campara, Klocwork, 1 Chrysalis Wat, Ottawa, Canada, K2G6P9,

[6] A Pattern Language, C. Alexander, S. Ishikawa, M. Silverstain, M. Jakobson, I. Fiksdahl-King and S. Angel, Oxford University Press, 1977, New York.

[7] Архитектура корпоративных программных приложений, Мартин Фаулер, Вильямс, Москва, 2004

[8] Алгоритмы: построение и анализ, Т. Кормен, Ч. Лейзерсон, Р. Ривест, МЦНМО, Москва, 2001

[9] Рефакторинг архитектуры программного обеспечения, М.В.Ксензов, ИСП РАН, Препринт 4, Москва, 2004

Место паттерна выделения слоев в рефакторинге архитектуры

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

Значение паттерна для анализа. Паттерн выделения слоев может быть применен для чистого анализа (раскопки) архитектуры. Для этого имеется несколько оснований. Выделение слоев – это прием, который в известной степени позволяет сократить и сделать более направленным семантический анализ системы за счет структурного анализа, что, несомненно, хорошо, поскольку семантический анализ – значительно более ресурсоемкий процесс. При этом нет никакой необходимость отражения слоев на программный код и инфраструктуру его хранения. Например, при анализе архитектурного кода программной системы, написанной на Java, выделение слоев не предполагает обязательного выделения пакетов, соответствующих этим слоям. Если специалист, проводящий архитектурный рефакторинг, принимает решение все-таки не отображать слои в пакеты языка Java, то можно считать, что выделение слоев было применено для чистого анализа архитектуры.

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

Отличия архитектурного и классического рефакторингов

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

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

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

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

Тестирование. В соответствии с [2] трансформации можно считать корректными, если они не приводят к изменениям поведения программной системы в целом. Наличие достаточно полного набора модульных (unit) тестов позволяет убедиться в корректности трансформаций. Именно это делает модульное тестирование одним из ключевых аспектов классического рефакторинга. Для архитектурного рефакторинга также встает задача автоматической проверки корректности трансформаций. Конечно, наличие модульных тестов повышает уверенность разработчика в корректности проведенных изменений даже при применении архитектурного рефакторинга. Тем не менее, на настоящий момент неизвестно, насколько эффективно модульное тестирование работает с методами рефакторинга архитектуры. Это, в частности, обуславливается разницей в масштабах изменений при классическом и архитектурном рефакторинге.

Паттерн

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

Имя: выделение слоев.

Ситуация: на диаграмме представлены элементы, для которых верны следующие условия:

Исходящие связи ведут только в последний выделенные слои (слой с номером n), или их нет, если ранее не был выделен ни один слой.

“Кандидаты на объединение в новый слой” c номером n+1 должны обладать общим смыслом и/или функциональностью. Простейшей проверкой на наличие общности является простой критерий: если для кандидатов можно подобрать "общее определение", то можно считать что они обладают требуемой общностью.

Рецепт: Объединить блоки в новый слой “n+1”. Отметим, что для двух произвольных слоев слой, обладающий большим порядковым номером, считается "вышележащим". Важно отметить, что если в результате применения паттерна было выделено n слоев, и еще остались блоки, которые в силу ограничений не смогли быть отнесены ни к одному из выделенных слоев и формально не могут быть выделены в новый слой, то эти блоки по-умолчанию считаются n+1 слоем, который в дальнейшем именуется "чердаком".

Примеры применения паттерна выделения слоев

Улучшение архитектуры и нестрогие слои. В работе [9] описывается случай, когда найденные нестрогие слои позволили выявить архитектурный дефект в программной системе toolbus, существенно затруднявший реализацию задачи, поставленной перед разработчиками. Программная система toolbus представляет для своих клиентов механизмы коммуникации. В системе используется набор стандартных сообщений, которые были реализованы на основе сокетов операционной системы и специализированного текстового протокола для обмена данными по сокетам (на рис 3 – за это отвечает слой “Layer 2: Protocol Implementation”). Чтобы изолировать тонкости текстового протокола от разработчиков, был реализован API системы, скрывающий как ее сокеты, так и передаваемые через них коды команд за набором процедур языка программирования (Layer 3: Toolbus API). Однако по мере развития в систему были добавлены вспомогательные механизмы (“Layer 4: Applications”). Именно эти механизмы и нарушали строгость слоистой структуры, поскольку они обращались к уровню работы сокетов в обход специфицированного API системы (связь от “Layer 4” к “Layer 3”).

Рисунок 3. Архитектура toolbus

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

Анализ архитектуры и поглощающие слои. Характерным примером, демонстрирующим пользу смягчения условий для поиска слоев с целью анализа архитектуры является ситуация, возникшая при анализе архитектуры Apache James 2.2. Apache James – это реализованный на Java мощный почтовый сервер масштаба предприятия, поддерживающий все наиболее распространенные современные почтовые протоколы и предоставляющий ряд дополнительных возможностей. После того, как для сервера Apache James была построена структурная модель, и в ней были выделены основные подсистемы, была предпринята попытка выделить в модели нестрогие слои.

При выделении слоев было разрешено поглощение СК. В результате была получена диаграмма 4 А). Эта диаграмма вполне осмыслена: на слое 1 оказались блокConstants.java, содержащий константы, используемые во всей системе, и блок Core, содержащий основные типы данных системы, такие как Message – сообщение, MessageHeader – заголовок сообщения и пр. Таким образом, слой 1 содержит основные определения системы. Слой 2 содержит authorization – систему контроля доступа, mailrepository – репозиторий писем, mailstore адаптер для mailrepository созданный для унификации работы с различными системами хранения и управления сообщениями, в том числе он может служить скрывать и mailrepository. Слой 3 – фактически, основной, поскольку содержит собственно ядро почтового сервера. На слое 4 располагаются вспомогательные механизмы для работы с почтовым сервером – система удаленного администрирования remotemanager и система fetch – облегчающая получение писем с сервера.
С другой стороны, попытка выделения нестрогих слоев, но без поглощения СК дала гораздо более слабый результат. Выделенные слои представлены на рис 4 Б). Из-за того, что в системе существует сильносвязанный компонент, в который входят блоки mailrepository и mailstore, на "чердак" попало большинство слоев системы, а дать слоям какое-либо внятное определение оказалось невозможно.

Рисунок 4. Анализ Apache James
Необходимо отметить, что СК, содержащий mailrepository и mailstore, свидетельствет о некоторой архитектурной проблеме. Как уже говорилось, mailstore – выступает как адаптер для mailrepository. Связь идущая от mailrepository к адаптеру свидетельствует о том, что изменение адаптера приведет к изменению адаптируемого объекта, что снижает гибкость архитектуры программной системы.

Рефакторинг архитектуры программного обеспечения: выделение слоев

Труды Института Системного Программирования РАН, 2004 г.

Слои в архитектуре ПО

Концепция слоев — одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. В среде сетевого взаимодействия протокол FТР работает на основе протокола ТСР, который, в свою очередь, функционирует "поверх" протокола IР, расположенного "над" протоколом Ethernet [7]. Итак, рассмотрим основные причины интереса к слоям архитектуры программных систем:

Слои легко формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n – это компонент или набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.

Слои обладают простой и наглядной семантикой. Как правило, в архитектуре программной системы слои представляют уровни абстракции. Слой n+1 использует слой

n, следовательно, абстракция понятий слоя n+1, по меньшей мере, не ниже чем у слоя n, а в идеале – если архитектура системы эффективна, его уровень абстракции должен быть выше. Соответственно, слой n скрывает (инкапсулирует) логику работы с понятиями определенными на этом слое, позволяя, таким образом, слою n+1 реализовать работу с более сложными понятиями, организовать более сложную логику, используя выразительные средства нижележащего слоя.

Слои широко распространены. Действительно, достаточно большое количество программных систем, особенно если речь идет о программных системах масштаба предприятия (enterprise systems), имеют именно слоистую структуру. Конечно, достаточно часто встречается ситуация, когда строгая послойная структура системы нарушается – как правило, это является следствием эрозии архитектуры (архитектурным дефектом) и ее устранение в большинстве случаев способно принести ощутимые выгоды (эти аспекты рассматриваются далее).

Альтернативная реализация. Можно выбирать альтернативную реализацию базовых слоев – компоненты верхнего слоя способны работать без каких-либо изменений в нижележащих слоях [7], при условии сохранения интерфейсов.

Минимизация интерфейсов. Зависимость между слоями, то есть, фактически, интерфейсы, предоставляемые нижними слоями верхним, можно свести к минимуму [7]. Такая минимизация интерфейсов – позволяет увеличивать гибкость системы.

Схема архитектурных слоев обладает и определенными недостатками [7]:

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

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

Имя блока: test, тип:

Таблица 1

Таблица 1

Корневая диаграмма		Содержит: Имя блока: test, тип: DIRECTORY
Диаграмма		Содержит: Имя блока: a.cpp, тип: FILE Имя блока: b.cpp, тип: FILE Отношение между a.cpp и a.h, тип INCLUDES Отношение между a.cpp и a.h, тип DECLARED-BY
Диаграмма a.cpp		Содержит: Имя блока: a, тип: FUNCTION Иcходящее отношение в блок a с диаграммы a.h, тип DECLARED-BY
Диаграмма a.h		Содержит: Имя блока: a, тип: FUNCTION-DECLARATION Входящее отношение из блока a с диаграммы a.cpp, тип DECLARED-BY

Тактика применения

Тактика применения паттерна выделения слоев имеет два основных аспекта: масштаб и время.

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

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

Время. Этот аспект касается того, когда нужно применять выделение слоев. Это достаточно хороший паттерн, чтобы с него начать анализ и рефакторинг архитектуры системы, особенно, если эрозия архитектуры не катастрофична. Выделение слоев ведет к тому, что рефакторинг архитектуры приобретает "направленность", задача сводится к меньшим подзадачам; теперь детальный семантический анализ можно применять только к тем слоям, которые имею непосредственное отношение к поставленной задаче. Тем не менее, как и всякий другой паттерн, выделение слоев особенно хорошо работает в связке с другими паттернами. Шансы на успех резко вырастут, если провести предварительную подготовку, применив как минимум "удаление мертвых блоков" и "инкапсуляцию приватных блоков", описанных в [9].

Виды слоев

Строгие слои. Это слои, описанные в разделе 2.1. Канонический вариант слоев, не допускающий никаких отклонений в строгой структуре и потому встречающийся относительно редко. На рис. 2 А) могут быть выделены следующие строгие слои: слой 1 – блоки с номерами 5, 6. Слой 2 – блоки 3, 4. Слой 3 – блоки 1, 2.

Как уже упоминалось, систем с четкой послойной структурой, также известной как строгие слои, значительно меньше, чем систем с

псевдослоями – то есть со структурой, близкой к послойной, но с допустимыми отклонениями. Далее рассматриваются некоторые виды послойных структур, используемых для рефакторинга архитектуры ПО.

Нестрогие слои (Non-strict layers). Смягчение условий: нестрогие слои допускают связи от вышележащего слоя к нескольким нижележащим слоям (потенциально – ко всем), а не только к непосредственному соседу снизу. Архитектура с нестрогими слоями может быть как результатом эрозии, так и осознанным решением.

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

На рис. 2 Б) показаны шесть нестрогих слоев – по одному блоку в каждом слое: слой 1 – блок 6, слой 2 – блок 5, слой 3 – блок 4 и т.д. В то же время, выделение строгих слоев даст значительно более грубую структуризацию: слой 1 – блок 6, слой 2 – блок 5. Все остальные блоки попадут на "чердак", так как дальнейшее выделение строгих слоев невозможно – блок 4 нарушает строгую структуру и обращается к первому слою в обход второго слоя. Все оставшиеся блоки используют блок 4 и, соответственно, тоже попадают на "чердак".

Поглощение сильносвязанных компонентов (СК).

Смягчение условий: уже рассмотренные виды слоев можно модифицировать, позволив включать в произвольный слой СК [8]. При таком подходе СК рассматривается, фактически, как атомарный элемент.
Без подобного смягчения условий как сам СК, так и все блоки которые могли бы попасть в вышележащие слои, будут отправлены на "чердак". Действительно, рассмотренные подходы не смогут расщепить СК на слои, и он автоматически попадает на чердак, так же, как и блоки, зависящие от него. Тем не менее, отнюдь не всегда СК на структурных диаграммах свидетельствуют о плохой архитектуре системы. Например, в системах с рассылкой сообщений достаточно часто встречается сильносвязанный компонент, подобный представленному на рис 1: источник событий "знает" о зарегистрированных в нем слушателях (listeners), слушатели знают о событиях (events), отправляемых источником, а в событии содержится ссылка на его источник. Таким образом, представляется удобным выделять слои и на тех диаграммах, которые содержат СК, именно поэтому было введено поглощение.

Рис 1. События, слушатели и источники событий.

Последствия: возможным дефектом архитектуры с поглощающими слоями может стать эффект "пропавшего слоя" – дефектная связь приводит к появлению СК, которые по смыслу должны находится на разных слоях.

На рис. 2 В) при использовании поглощения СК можно выделить те же слои, что и в случае применения строгих слоев к 2 А). Слой 1 – блоки 5, 6. Слой 2 – блоки 3, 4. Слой 3 – блоки 1, 2. Если применять обычный поиск строгих слоев, то все блоки окажутся на "чердаке".

На рис. 2 Г) при использовании поглощения СК можно выделить слой 1 – блок 6, слой 2 – блок 5, слой 3 – блоки 3, 4, слой 4 – блоки 1, 2. Если применять обычный поиск нестрогих слоев, блоки 1, 2, 3, 4 окажутся на "чердаке", то есть структуризация в таком случае будет значительно хуже.



Рисунок 2. Примеры диаграмм.

В последнее время наблюдается тенденция

В последнее время наблюдается тенденция к увеличению продолжительности жизненного цикла успешных программных проектов. Как следствие, растет объем унаследованного кода, поддерживаемого сообществом разработчиков [1]. Именно это объясняет исключительную важность задач, связанных с облегчением сопровождения и развития существующего программного кода. В то же время, этим задачам уделяется недостаточное внимание со стороны научного сообщества и разработчиков инструментальных средств. Как следствие, современные методики переоценивают значение начальной фазы жизненного цикла программной системы и практически игнорируют ее дальнейшую эволюцию. Таким образом, в настоящее время существует явный недостаток методик и эффективных инструментов поддержки работы с существующим кодом.
В последнее время наметился перелом ситуации: стали вызывать значительный интерес вопросы систематического использования трансформаций как центрального организующего принципа процесса развития и сопровождения существующего программного обеспечения. Однако большинство исследователей рассматривает трансформации достаточно узко – как трансформации на уровне исходного кода – рефакторинг [2]. Тем не менее, в настоящее время практически не существует исследований, посвященных трансформации на более высоком уровне абстракции – уровне архитектуры ПО. В то же время, многие сценарии сопровождения и развития существующего кода подразумевают изменение архитектуры существующей системы. В связи с этим, большой интерес вызывает разработка методики и сопровождающих ее инструментальных средств, нацеленных на организацию предсказуемого и управляемого процесса изменения архитектуры ПО.
В данной работе рассматриваются один из основных методов рефакторинга архитектуры ПО – выделение слоев, а также его место в контексте рефакторинга архитектуры как многошагового итеративного процесса.

Выделение слоев

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

Значение паттерна "выделение слоев" легко объяснимо - слои обладают целым рядом замечательных свойств, делающих их незаменимым инструментом структуризации системы.

Зачем менять архитектуру?

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

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

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

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

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

Выделение слоев является одним из

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

Анализ и оценка приоритетности

Выявленные риски следует проанализировать. Анализ включает оценку вероятности риска и его возможных последствий в кратко- и долгосрочном плане.

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

Если же риск новый, его нужно оценить. По результатам опросов и интервью или по аналогии с ранее выполнявшимися проектами для риска оценивается вероятность проявления и тяжесть последствий. К сожалению, в таких случаях редко удается получить сколько-нибудь точные численные оценки. Тем не менее обычно не составляет труда выбрать для риска одно из заранее определенных значений вероятности (например, из уже упоминавшегося ряда от 0,1 до 0,9) и целочисленное значение тяжести последствий (скажем, от 1 до 5). Сделать это проще, чем оценить последствия в реальных деньгах. Вместе с тем такой оценки обычно хватает для решения главной проблемы — выделения наиболее приоритетных рисков. В результате возможные показатели приоритета (произведения вероятности проявления риска на тяжесть последствий) будут варьироваться в пределах от 0,1 до 4,5 (см. таблицу).

Таблица. Возможные значения приоритетов рисков

	0.1	0.3	0.5	0.7	0.9
1	0.1	0.3	0.5	0.7	0.9
2	0.2	0.6	1.0	1.4	1.8
3	0.3	0.9	1.5	2.1	2.7
4	0.4	1.2	2.0	2.8	3.6
5	0.5	1.5	2.5	3.5	4.5

Как правило, риски с текущим значением приоритета меньше 1 (выделены зеленым) просто игнорируются. Риски со значением приоритета в диапазоне 1—2 оставляются в списке, но реальных действий по их устранению обычно не предпринимается. Основное же внимание уделяется рискам с приоритетом больше 2.

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

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

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

Диалог с оппонентом

Типичный диалог специалиста по управлению рисками (Специалист) с менеджером проекта (МП), которому предстоит внедрять управление рисками в своем проекте, выглядит примерно так.

МП: Зачем нужно управлять рисками? Может быть, в нашем проекте их вообще нет?

Специалист: Вот признаки, которые часто указывают на рискованный характер проекта:

большие размеры разрабатываемой системы;

неясные и изменяющиеся требования;

использование в проекте новых технологий;

сложность системы;

размеры системы, не соответствующие бюджету;

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

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

неправильно оценить реальный размер и сложность задач разработки;

недостаточно точно оценить необходимые ресурсы;

превысить возможности (компетенцию) организации;

не обеспечить стабильность пожеланий пользователя;

использовать недостаточно зрелые программные среды и инструменты;

назначить сроки выполнения проекта без учета реальных размеров и сложности системы;

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

понадеяться на “серебряную пулю”, которая позволит резко повысить производительность.

МП: Тогда, может быть, лучше посмотреть, какие именно риски реализуются, и потом бороться с возникшими проблемами?

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

Этапы освоения

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

Стадия 1. Решение проблем

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

Стадия 2. Снижение последствий

Это стадия соответствует началу внедрения управления рисками. Руководство проекта уже само спрашивает: “А что может не получиться? Какие могут возникнуть проблемы? А какие будут последствия?”. Команда понимает, что такое риск. Но еще не всегда хватает опыта для того, чтобы обсудить все необходимые детали. На этой стадии руководство обычно предпочитает формировать резервные планы, чтобы использовать их, если основной план провалится.

Стадия 3. Предотвращение рисков

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

Стадия 4. Предвосхищение рисков

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

Стадия 5. Учет возможностей

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

В заключение осталось пожелать всем успешно освоить все перечисленные стадии. А чтобы наверняка этого добиться — управляйте рисками!

Мониторинг рисков

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

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

Некоторые практические рекомендации

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

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

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

Отсутствие резервов может вызвать очень тяжелые последствия вплоть до полной остановки работ по проекту. Объем резервов должен согласовываться с текущей оценкой рисков. При использовании части средств для борьбы с проявившимся риском объем резервов должен быть пересмотрен и при необходимости увеличен.

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

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

Определять критерии формирования таких предупреждений можно с помощью различных методов анализа временных рядов для “долгоиграющих” рисков. Формирование критериев в любом случае требует определенного опыта работы по управлению рисками и набора предварительной статистики.

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

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

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

Основные понятия

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

Введем несколько формальных определений.

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

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

Вероятность риска — вероятность, с которой данный риск превратится в проблему. Здесь также применима качественная шкала (пренебрежимая вероятность, малая и т. д. — вплоть до весьма вероятной). Но могут использоваться и численные значения (обычно выбирают некоторый набор типовых значений, например, 0,1; 0,3; 0,5; 0,7; 0,9).
Следует отметить, что событие, которое должно обязательно произойти, не является риском, и действия, которые необходимо в связи с ним предпринять, определяются в рамках обычного планирования и управления, а не управления рисками.

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

Наиболее часто используются следующие стратегии борьбы с риском.

1. Избежать риска. Реорганизовать проект таким образом, чтобы он не зависел от данного события. Например, при разработке ПО можно исключить вызывающую сомнение функциональность. К сожалению, таким образом редко удается полностью удовлетворить заказчика.

2. Переадресовать риск. Исполнитель прибегает к своего рода страховке — если проявится риск, заказчик берет на себя оплату дополнительных работ. В случае реализации такого риска руководство компании обязуется привлечь к проекту еще некоторое количество сотрудников.

3. Согласиться с присутствием риска. Это не означает, что не надо ничего делать, а просто пассивно ждать реализации риска. Согласившись с присутствием риска, можно предпринять некие действия, направленные на снижение вероятности его проявления, уменьшение его последствий (например, предусмотреть такую архитектуру системы, которая позволит компенсировать потерю производительности) либо разработать план альтернативных действий (например, перехода на другую СУБД), который будет выполняться, если риск реализуется.

Список рисков — упорядоченный по приоритету список выявленных и отслеживаемых рисков.Приоритет определяется как произведение вероятности на величину воздействия (в условных единицах).

Основные проблемы

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

Если спросить у рядового разработчика или руководителя, почему в их фирме нет процесса управления рисками, можно услышать массу самых разных ответов. Тут будет и самое простое: “У нас нет рисков”, и более изощренные варианты: “Мы боремся с проблемами по мере их возникновения”, “Наше дело — разработка программы, а не заполнение бюрократических форм”, “Использование этого инструмента не рискованно. Так нам сказал поставщик”. Реальные же причины нелюбви к управлению рисками чаще всего кроятся в следующем.

Прежде всего руководство боится отойти от традиционной позиции “мы это обязательно сделаем”. Управление рисками предполагает, что могут быть и неудачи. А отсюда и следующая причина: руководство часто рассматривает управление рисками как способ, позволяющий подчиненным обосновать будущее поражение. Хотя реально речь идет как раз о мерах по повышению вероятности успешного выполнения проектов.

Руководители проектов тоже нередко побаиваются управления рисками. Они считают, что если заранее выявленный риск все-таки реализуется, это будет рассматриваться как их ошибка. Хотя реально такая ситуация обычно позволяет продемонстрировать, насколько удалось снизить потенциальные последствия риска с помощью превентивных мер.

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

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

Планирование ответных действий

Для каждого из рисков, вошедших в список приоритетных, необходимо выбрать стратегию реагирования. Как уже говорилось, стратегия может быть направлена на то, чтобы “обойти” риск, застраховаться от него или смягчить его последствия. Иногда риск можно исключить полностью, отказавшись от одного-двух низкоприоритетных свойств системы. В других случаях можно попытаться использовать более зрелые или лучше известные разработчикам технологии.

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

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

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

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

Для рисков, не устраненных окончательно или не поддающихся "смягчению", нужно разработать хотя бы предварительный резервный план действий на случай их проявления (часто его называют “план Б”).

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

Планирование управления рисками

В планировании управления рисками есть ряд главных моментов.

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

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

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

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

Сведения об авторах:

Автор работает в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК, г. Москва.

Закис Алексей – главный специалист управления методологии создания и сопровождения программного обеспечения.

Если Вас заинтересовал данный материал, то можете присылать вопросы по адресу: , .

Выявление рисков

Риски, с которыми приходится иметь дело в проектах разработки ПО, можно условно разбить на несколько типов:

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

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

3. Риски на этапе сопровождения системы, в том числе связанные с размещением ПО у заказчика, поддержкой, обучением и т. п.

4. Стоимостные риски, связанные с превышением затрат или проблемами финансирования проекта.

5. Риски сроков, связанные с необходимостью ускорить разработку из-за внешних причин.

6. Риски неудовлетворенности заказчика.

Чтобы определить риски проекта, обычно используются следующие четыре метода.

Исторический анализ. Сравнение данного проекта с аналогичными, выполненными ранее. Вчерашние проблемы часто остаются рисками в новых проектах.

Аналитический метод. Включает такие технологии, как моделирование, анализ по схеме "причина-результат", анализ таблиц истинности и т. д.

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

Индивидуальные интервью. Проводятся как с руководством проекта, так и с рядовыми участниками. По желанию интервьюируемых они могут остаться анонимными и не упоминаться как “источники” риска. Сотрудники могут даже присылать свои сообщения анонимно по электронной почте — анонимность позволяет избежать опасений, что “принесшего дурную весть накажут”.

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

Задачи управления рисками

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

Планирование управления рисками. План должен описывать общие подходы к управлению рисками в проекте и основные действия, которые придется выполнять.

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

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

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

Мониторинг рисков. Цель данной меры — изменение приоритетов и планов преодоления рисков при изменении их вероятности и последствий, а также своевременное выявление рисков, которые реализуются в данный момент. По сути представляет собой повторение шагов выявления и анализа рисков.

Рассмотрим перечисленные задачи более детально.

Алгоритм построения машин состояний по диаграммам последовательностей

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

синтаксический разбор (parsing); построение графов, соответствующих диаграммам (ordering/linking); объединение поведений, заданных диаграмма (placement/integration); построение срезов (slicing); построение автоматов, их преобразование в детерминированные автоматы, трансформация в машины состояний (automata generation & minimization); кодогенерация (codegeneration).

Кратко опишем эти фазы.

Фазы синтаксического разбора и построения графов диаграмм зависят от синтаксиса их записи. В результате для каждой диаграммы обзора взаимодействий строится внутреннее представление графа, который состоит из диаграмм и связей между ними, задающих их последовательность. Для диаграмм последовательностей строятся события (и так называемые псевдособытия) и связи, задающие их последовательность на данной оси. Для inline-конструкций и ссылок на другие диаграммы строятся псевдособытия. Также строятся связи между множествами событий (и псевдособытий) на разных осях, если они взаимосвязаны - т.е. для пар событий посылки-приема сообщения, псевдособытий, соответствующих началам и концам ссылок на другие диаграммы, началам и окончаниям inline-конструкций.

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

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

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

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

Описанный алгоритм реализован для MSC-диаграмм в синтезаторе Bridge, разработанном в Институте системного программирования РАН совместно с компанией Klocwork. По построенным автоматам может генерироваться модель системы на языке SDL (очень близком к протокольным машинам состояний UML), прототип системы на языках Си/C++ или Java, тесты для системы на языках TTCN и PPL.

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

Рис. 15. Машины состояний для объектов модельной системы обмена данными.

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

Формализация понятия роли

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

Использование ролей в сценариях взаимодействия

,
Труды Института системного программирования РАН

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

Композиция через конструкции «продолжения»

Спецификация UML предлагает дополнительный способ композиции поведения через конструкцию продолжения (continuation) осей. Семантика таких конструкций носит характер «склейки» поведения по меткам: после фрагмента взаимодействий, заканчивающегося конструкцией продолжения с именем "X", допустимо продолжение по тем ветвям следующего фрагмента взаимодействий, которые начинаются с конструкции продолжения с тем же именем "X". Это может быть проиллюстрировано примером, взятым из спецификации UML: диаграмма Continue со ссылкой на диаграмму Question (Рис. 8) эквивалентна диаграмме, представленной на Рис. 9.

Рис. 8. Пример из спецификации UML: композиция с помощью конструкции «продолжения»

Рис. 9. Пример из спецификации UML: результат композиции с помощью конструкции «продолжения»

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

Тогда можно рассмотреть спецификацию системы обмена данными, представленную на Рис. 10, которая будет эквивалентна исходной (Рис. 2), в предположении, что объекты A и B в исходном случае - это узлы некоторого одного типа Node.

Рис. 10. Спецификация модельной системы обмена данными с помощью конструкций «продолжения»

Данная спецификация задает поведение объектов типа Node. Каждый вариант взаимодействия в этой спецификации описан один раз для своего набора ролей, однако несколько утеряна наглядность, присущая диаграммам взаимодействия, вследствие необходимости отслеживать имена меток конструкций продолжения.

в этой спецификации есть некоторая

Следует отметить, что в этой спецификации есть некоторая неопределенность, связанная с тем, что в самом начале взаимодействия не задан способ выбора роли (Sender или Receiver) объектом типа Node. Эта неопределенность может приводить в данном случае к тупиковым ситуациям в функционировании системы, когда объекты совместно начинают выполнять роль Receiver, в результате чего бесконечно ожидают приема сигнала.

Такое расширение композиции через конструкции продолжения дополнительно обеспечивает следующую заслуживающую внимания возможность. Рассмотрим систему, состоящую из вычислителя (Calculator), который может вычислять функции f1 и f2 и терминалов (Terminal), обращающихся к нему за вычислением этих функций. Пусть терминал должен запрашивать вычисление функций, чередуя f1 и f2, а вычислитель должен обладать возможностью производить вычисления функций в любом порядке. Поведение этой системы может быть описано с помощью диаграмм, представленных на Рис. 11.

Рис. 11. Спецификация системы вычислителя с несколькими терминалами

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



Рис. 12. Поведение вычислителя

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

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

Композиция через параметризацию диаграмм по осям

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

Спецификация UML не говорит явно о возможности параметризации имен осей, однако заметим, что стандарт MSC позволяет задавать имена осей в качестве параметров MSC-диаграммы.

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

Рис. 13. Спецификация модельной системы обмена данными с помощью параметризации диаграмм по осям

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

Заметим, что в данном случае пришлось продублировать описания ссылок на описания протоколов; вместо этого можно попытаться явно описывать задающие значения параметров потоки объектов между диаграммами,.

Композиция через задание потоков объектов

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

Рис. 14. Спецификация модельной системы обмена данными с помощью явного задания потоков объектов

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

Композиция поведения в разных ролях

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

Отображение в другие модели

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

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

Отображение в модель активностей

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

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

Рис. 19. Отображение взаимодействий в активности

Отметим, что существуют работы, в которых рассматриваемся формализация исполняемой семантики взаимодействий через сети Петри - см. [].

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

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

Также возможно отображение машин состояний в диаграммы активностей []. Можно сделать предположение, что существо различия между моделью активностей, построенной по UML-взаимодействиям, и моделью активностей, построенной по машинам состояний, которые сгенерированы из тех же UML-взаимодействий, заключается в том, что моделирование передачи сообщений в первом случае происходит отдельными потоками сообщений между активностями посылки и приема, а во втором представляет собой некоторый общий поток, соответствующий каналу передачи. В этом случае модель активностей потенциально может являться некоторым базисом для сравнения поведений.

Отображение в модель машин состояний

Для спецификации поведения объектов системы применяются подходы, основанные на событийных автоматах; в таком случае поведение каждого компонента системы задается расширенным конечным автоматом. Событийные автоматы довольно легко отображаются в код на целевых языках; кроме того, существуют такие распространенные нотации как SDL [] и машины состояний UML, в которых используется семантика автоматов.

Под машинами состояний (State Machines) мы понимаем расширенные конечные автоматы в алфавите событий, возможных в системе. Для этих автоматов должны выполняться некоторые дополнительные требования, которые заключаются в выделении некоторых типов состояний автомата, различающихся видами событий, по которым возможны переходы из этих состояний. Эти виды следующие:

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

Состояния ожидания автоматов соответствуют собственно состояниям машин, остальные состояния автоматов соответствуют так называемым псевдосостояниям.

Расширение алгоритма синтеза при использовании средств для композиции ролей

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

Для возможности построения композиции с помощью конструкций продолжения требуется некоторое расширение алгоритма, позволяющее производить такую «склейку» осей.

Рассматриваемые расширения алгоритма синтеза касаются фаз подстановки и построения срезов.

Роли в моделях взаимодействия

Описание взаимодействий в виде диаграммы последовательностей представляет собой набор осей (lifelines), некоторым образом сопоставляемых объектам, каждая из которых задает порядок наступления определенных событий для соответствующего объекта и выполнения им некоторых действий.

Мы будем придерживаться следующего соглашения об использовании синтаксиса именования оси:

<идентификатор_оси> ::= [<имя_элемента>] [: <имя_класса>]

(причем <идентификатор оси> не может быть пустым).

Трактоваться <идентификатор_оси> будет следующим образом: <имя_элемента> обозначает имя роли объекта, которому данная ось ставится в соответствие, а <имя_класса> - тип объекта. В случае, когда опущено имя роли, предполагается, что объект играет некую, так называемую, анонимную роль. Если опущено имя класса, предполагается, что тип объекта может быть произвольным.

В качестве близкого к реальным системам примера рассмотрим модель сети мобильной связи, в которой есть телефоны (Telephone), передатчики (Transmitter) и центральный коммутатор (Switch). Для такой системы можно выделить следующие протоколы:

установление соединения; передача данных (разговор); разрыв соединения; регистрация в сети; смена станции в сети.

Мы не будем описывать полную сценарную спецификацию для этой системы, однако приведем ее некоторые возможные сценарии (Рис. 1): запрос на установление соединения (Connection), передача данных (Transmitting), смена станции (Relocation).

Рис. 1. Сценарии системы мобильной связи

По приведенным сценариям видно, что для, например, телефонного аппарата абонента (Telephone) существуют, по крайней мере, такие роли как:

Caller - аппарат вызывающего абонента; Calleе - аппарат вызываемого абонента; Sender - аппарат, отправляющий голосовые данные; Receiver - аппарат, принимающий голосовые данные; Migrator - аппарат, сменяющий текущую станцию (передатчик).

Рассматривая эти роли, можно уже указать на важность построения композиции поведения - ясно, например, что роли Sender и Receiver могут выполняться аппаратом после ролей Caller или Callee, причем роли Sender и Receiver могут выполняться аппаратом одновременно.
Поведение, соответствующее роли Migrator, аппарат может выполнять одновременно с любой другой из этих ролей. На этом примере видно, что задание композиции поведения объектов в разных ролях может быть важно для адекватного описания поведения как системы.

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

Итак, рассмотрим систему обмена данными (Рис. 2), состоящую из двух узлов A и B, которые могут по очереди обмениваться сообщениями с данными (data) до тех пор, пока один из них не пошлет сообщение о завершении серии обменов (stop).

Рис. 2. Спецификация модельной системы обмена данными

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

Рис. 3. Взаимодействия в системе обмена данными.

Протокол передачи данных описывает поведение двух сторон - объекта, играющего роль отправителя данных (DataSender), и объекта, играющего роль получателя данных (DataReceiver). В контексте завершения сеанса передачи можно говорить о роли объекта, инициирующего завершение (TerminationInitiator), и роли объекта, извещаемого о завершении (TerminationAcceptor). В этом примере следует обратить внимание, на то, что, прибегая к абстрагированию, можно говорить не об описании поведения объектов, а об описании поведения ролей, которые объекты могут выполнять.

В данной спецификации эти протоколы пришлось продублировать для вариантов разных сочетаний объектов A и B и их возможных ролей.

Теперь рассмотрим следующие два вопроса:

Если объекты A и B - различных типов, то как избежать дублирования описания общего для них поведения? Если объекты A и B одинакового типа, то как описать композицию поведения объектов этого типа?

С использованием понятия ролей эти вопросы могут быть переформулированы следующим образом:

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

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

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

Роли в сценариях взаимодействия

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

В модели взаимодействий UML при описании некоторого сценария каждой роли естественно сопоставлять оси с одинаковым именем на различных диаграммах. В контексте некоторого упрощения метамодели взаимодействий UML (Рис. 5) взаимосвязь ролей с моделью взаимодействий можно проиллюстрировать диаграммой, представленной на Рис. 6.

Рис. 5. Фрагмент упрощенной модели взаимодействий UML

Рис. 6. Роли в метамодели взаимодействий

Список литературы

1.	UML 2.0 Superstructure Specification FTF. October 8, 2004, OMG Document: ptc/04-10-02 (convenience document).
2.	B. Bollig, M. Leucker, T. Noll. Generalised Regular MSC Languages. Proceedings of the 5th International Conference on Foundations of Software Science and Computation Structures (FOSSACS '02), Grenoble, France, 2002.
3.	B. Jonsson, G. Padilla. An Execution Semantics for MSC-2000. SDL 2001: Meeting UML, 10th International SDL Forum Copenhagen, Denmark, 2001.
4.	ITU Recommendation Z.120 Message Sequence Charts (MSC-2000). International Telecommunication Union (ITU), Geneva, 1999.
5.	F. Steimann. On the Representation of Roles in Object-Oriented and Conceptual Modelling. Data & Knowledge, Volume 35, Issue 1, October 2000.
6.	R. K. Wong, H. L. Chau, F. H. Lochovsky. A Data Model and Semantics of Objects with Dynamic Roles. Proceedings of the Thirteenth International Conference on Data Engineering table of contents, 1997
7.	F. Steimann. Role = Interface: a merger of concepts. Journal of Object-Oriented Programming 14:4, 2001
8.	M. Fowler. Dealing with Roles. Working Draft (http://martinfowler.com/apsupp/roles.pdf), July 1997.
9.	E. A. Kendall. Aspect-Oriented Programming for Role Models. Lecture Notes Computer Science, Vol. 1743, 1999.
10.	G. Georg, R. B. France. UML Aspect Specification Using Role Models. OOIS 2002: Object-Oriented Information Systems, 8th International Conference, Montpellier, France, 2002.
11.	M. Becht, T. Gurzki, J. Klarmann, M. Muscholl. ROPE: Role Oriented Programming Environment for Multiagent Systems. Proceedings of the 4th IFCIS Conference on Cooperative Information Systems (CoopIS'99), Edinburgh, Scotland, September 1999.
12.	ITU-T Recommendation Z.100 System Description and Definition Language (SDL-2000). International Telecommunication Union (ITU), Geneva, 1999.
13.	N. Mansurov, D. Vasura. Approximation of (H)MSC semantics by Event Automata. SAM'2000 workshop, Grenoble, France, 2000.
14.	St. Heymer. A Semantics for MSC Based on Petri-Net Components. SAM 2000, 2nd Workshop on SDL and MSC, Col de Porte, Grenoble, France, 2000.
15.	Z. Hu, S. M. Shatz. Mapping UML Diagrams to a Petri Net Notation for System Simulation. Proceedings of the 16th International Conference on Software Engineering & Knowledge Engineering (SEKE'2004), Banff, Alberta, Canada, 2004.

Структуризация поведения по ролям

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

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

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

Для рассматриваемого примера обмена данными такие подмашины весьма тривиальны (Рис. 16).

Рис. 16. Подмашины состояний, соответствующие поведению объектов в различных ролях

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

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

В качестве менее тривиального способа структурной реализации ролей можно рассмотреть шаблон, соответствующий использованию ролевого объекта в работе [] (Рис. 17).

Рис. 17. Шаблон «ролевой объект» для представления ролей в структуре системы

Если в системе существует поведение, связанное с некоторой ролью, то для такой роли заводится интерфейс Role и реализация этого поведения - Role_Impl. Если объекты типа Class могут выполнять эту роль, то такой класс должен быть унаследован от интерфейса Role, и он должен агрегировать объект типа Role_Impl, который по своей сути соответствует экземпляру роли. Поведение же, соответствующее данной роли, должно делегироваться в Class из Role_Impl.

Для примера с передачей данных, если считать типы объектов A и B разными, структура системы будет описываться диаграммой на Рис. 18.

Рис. 18. Машины состояний для объектов модельной системы обмена данными, структурированные по ролям

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

Свойства ролей

В литературе понятие роли используется преимущественно в контексте моделей данных и в архитектурных моделях. В таких работах исследуются средства структурной композиции свойств объекта из свойств его ролей; нас же будет интересовать, прежде всего, объединение функциональности, соответствующей поведению в различных ролях. Тем не менее, сами свойства ролей, как в структурном, так и в поведенческом аспектах сходны. Основываясь на обзоре, произведенном в [], отметим следующие свойства ролей:

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

Эти свойства ролей прослеживаются и в сценариях.

Подчеркнем различие между классами и ролями:

классы задают свойства отдельных объектов; роли задают позицию и ответственность (responsibility) объекта в рамках некоторой системы или подсистемы.

Удобно различать понятие роли и экземпляра роли - по аналогии с различением понятий класса и экземпляра класса. Под существованием во время выполнения (run-time) экземпляра роли мы будем понимать факт выполнения экземпляром агента или компонента системы данной роли в процессе некоторого взаимодействия.

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

Метамодель, иллюстрирующая эти соотношения, может быть описана диаграммой, представленной на Рис. 4.

Рис. 4. Метамодель, описывающая соотношения между ролями, классами и их экземплярами

Абстракция роли достаточно исследована с точки зрения ее структурной реализации, например, модели данных, использующие роли [], связь понятия роли и интерфейса [], шаблоны реализации ролей []; однако с точки зрения объединения поведения в различных сценариях роли практически не исследуются.
Произведем краткий обзор шаблонов для представления ролей, рассматриваемых в работе []:
объединение в единый тип для ролей (single role type) - все особенности каждой из ролей объединяются в один общий тип; использование отдельного типа для каждой роли (separate role type) - каждая роль трактуется как отдельный тип; использование ролевого объекта (role object) - особенности, присущие роли, объединяются в специальный объект; основной объект является хостом (host object), объединяющим несколько таких ролевых объектов; при обращениях внешних объектов он использует нужный из ролевых объектов в зависимости от контекста; использование ролевого отношения (role relationship) - специальный объект, объединяющий особенности данной роли, моделирует связь основного объекта в данной роли с некоторым внешним объектом.
Структурировать описание поведения можно различным образом; при рассмотрении поведений, соответствующих различным ролям в рамках некоторой архитектурной ролевой модели, можно достичь соответствия между ролями в их структурном и поведенческом понимании.

Уточнение семантики композиции

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

В дальнейшем под обзорными диаграммами взаимодействия, мы понимаем соответствующие диаграммы UML (UML Interactions Overview Diagrams), им родственна нотация высокоуровневых диаграмм MSC (High-level MSC, HMSC).

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

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

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

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

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

Предусловие зависит от вида такого события следующим образом:

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

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

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

Рассмотрим теперь следующие методы описания композиции поведения в различных ролях

использование специальных меток для «склейки» поведения; использование параметризуемых по осям диаграмм; задание потоков объектов на обзорных диаграммах взаимодействий.

предложенный консорциумом OMG, направлен на

Модельно-ориентированный подход (Model Driven Architecture, MDA), предложенный консорциумом OMG, направлен на достижение интероперабельности разрабатываемых систем. В нем используется идея разделения бизнес-логики проектируемой системы и конкретной технологии ее реализации. Для описания бизнес-логики используются платформо-независимые модели проектируемой системы. В рамках этого подхода основополагающую роль играет построение моделей системы, проверка их корректности и отображение в модели других уровней. Для унификации моделирования различных аспектов системы в рамках подхода MDA предлагается использовать универсальную нотацию - язык UML [].
На ранних фазах проектирования программных системы, особенно на фазе анализа требований, с успехом используется сценарный подход, заключающийся в определении вариантов использования (use cases) системы и описания сценариев ее поведения в каждом таком варианте. Каждый сценарий представляет собой описание последовательности взаимодействий, направленной на достижение некоторой цели. Сценарии могут быть заданы с помощью какой-либо нотации, позволяющей описывать поведение, однако, как правило, для описания сценариев используются нотации, обладающие высокой степенью наглядности.
Построение формализованной сценарной модели позволяет производить как статический анализ требований, так и генерировать исполняемый прототип системы для динамического исследования системы; тем самым достигается возможность проверки требований.
Для построения поведенческих моделей в языке UML 2.0 существуют следующие средства:
взаимодействия (interactions), семантика которых задает отношение частичной упорядоченности событий в различных компонентах системы и акторов, активности (activities), семантически эквивалентные иерархическим раскрашенным сетям Петри, машины состояний (state machines), использующие семантику расширенных конечных автоматов в алфавите событий системы.
По сути, взаимодействия UML обеспечивают абстракцию трасс системы, активности - абстракцию потоков (управления и данных) в системе, а машины состояний - абстракцию последовательности состояний для каждого компонента системы.

Взаимосвязь с аспектами

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

Рис. 7. Взаимосвязь ролей и аспектов с взаимодействиями UML

Исследования взаимосвязей в использовании ролей и аспектов можно найти, например, в [] и [].

В статье было продемонстрировано, что,

В статье было продемонстрировано, что, в отличие от традиционной интерпретации, каждое описание взаимодействий может трактоваться как ориентированное не на собственно объекты, а на роли, выполняемые ими в данном взаимодействии. Для более широкой применимости моделей взаимодействий и более формального их использования можно использовать рассмотренный аппарат для оперирования этими ролями.
В данной работе показано, как можно адаптировать имеющуюся нотацию UML для описания ролей, прежде всего, в плане задания их композиции. Для этого было рассмотрено использование конструкций продолжения и расширение возможностей параметризации UML-взаимодействий, однако у каждого из этих способов имеются свои недостатки. Следует отметить, что композиция через конструкции продолжения ближе к машинам состояний, так как семантика этих конструкций близка семантике к переходам на метку; композиция же через параметризацию - ближе по смыслу к семантике UML-активностей, так как она тем или иным образом задает потоки объектов.
В качестве модели для абстрактного выполнения были рассмотрены машины состояний UML, которые удобны для целей симуляции и генерации прототипа компонентов системы. Было рассмотрено расширение алгоритма синтеза машин состояний по UML-взаимодействиям на случай использования композиции различных ролей, и указаны те из этих расширений, которые поддерживаются разрабатываемым инструментом Bridge, позволяющим автоматически производить подобный синтез. Кроме этого, была обозначена возможность отображения модели UML-взаимодействий в модель активностей, которая удобна для анализа поведения системы в целом. Анализ моделей, поведение которых дает аппроксимацию поведения, задаваемого описаниями требований к системе в виде моделей взаимодействий, обеспечивает возможность выявлять пробелы в понимании требований к системе.
Другим результатом экспериментов с новой нотацией является вывод о том, что при композиции различных ролей, как и вообще при композиции сценариев, могут возникать неопределенности.
В статье был приведен типичный пример возникновения неопределенности с выбором роли, в результате которого у системы может существовать поведение, приводящее к тупиковой ситуации.
Еще одним следствием использования ролей при использовании для описания сценариев модели взаимодействий является достижение взаимосвязи с аспектно-ориентированным программированием.
В качестве развития данной тематики имеет смысл рассмотреть следующие задачи:
описание преобразований UML-взаимодействий в UML-машины состояний в терминах метамодели языка UML или некоторого ее упрощения; строгая формализация исполняемой семантики композиции UML-взаимодействий через диаграммы обзора взаимодействий; исследование ситуаций возникновения неопределенностей, связанных с композицией ролей, на основе расширении алгоритма синтеза машин состояний по взаимодействиям UML; исследование возможности генерации модели активностей UML по моделям последовательностей и их взаимосвязь с исходными моделями и с моделями машин состояний, полученными по тем же моделям взаимодействий.

"Естественный отбор" руководителя проекта

Гаврилов Н. Н., к.т.н., доц. РЭА им. Г.В. Плеханова

Козлов А. С., к.э.н., доц. ГУУ

Матвеев А. А., аспирант ИПУ РАН, сотрудник ПМСОФТ

Рост крупного бизнеса – результат естественного отбора.

Джон Рокфеллер

Качества, необходимые руководителю проектом

Можно с уверенностью сказать, что руководитель проекта должен, прежде всего, обладать основными качествами руководителя. Рассмотрению основных качеств и требований к руководителю посвящено множество работ. Для нас же гораздо больший интерес представляет выявление специфических качеств, которые необходимы управляющему проектом в связи со спецификой проектной деятельности. В качестве «специфики» проектной деятельности будем, в соответствии с PMBOK [3], рассматривать свойства временности и уникальности проектов.

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

с одной стороны, не должен «цепляться» за свое место в проекте и быть морально готовым по его завершении формально остаться без работы (по крайней мере, до вступления в управление новым проектом);

с другой стороны, руководитель проекта должен вкладывать все свои силы и душу в выполнение текущего проекта и достижение поставленных целей проекта.

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

Для иллюстрации такой ситуации введем качественные показатели «требования проекта» и «квалификация руководителя проекта». Под понятием «требования проекта» будем понимать совокупный уровень знаний и навыков, необходимых для успешной реализации проекта. Под понятием «квалификация руководителя проекта» будем понимать совокупный уровень знаний и навыков, которыми обладает руководитель проекта на определенный момент времени. Требования проекта и квалификация руководителя проекта – это динамичные характеристики.

Графическая иллюстрация понятий «требования проекта» и «квалификация руководителя проекта» приведена на рисунке 1.

Рисунок 1. Качественные соотношения динамики требований проекта и квалификации руководителя проекта

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

Так как для выполнения конкретных проектов требуются вполне определенные предметные и междисциплинарные знания и навыки. И, естественным образом, возникает вопрос: «Сколь глубокими и широкими должны быть знания и умения руководителя проекта?». Очевидно, что для сложных проектов требования достаточно высоки и разнообразны. Один человек вряд ли может быть профессионалам во всех областях. Решением этой проблемы является формирование команды проекта, состоящей из профессионалов в различных предметных областях, на которые распространяются требования проекта. При этом руководитель проекта должен реализовывать интегрирующие и синергетические функции. Сама же команда проекта, помимо реализации задач управления проектом, должна выполнять функции «инкубатора» будущих руководителей проектом и включаться в систему «естественного отбора».

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

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

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


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

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

решать проблемы, которые не могут быть полностью предоставлены другим предметным специалистам;

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

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

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

работать и договариваться со всеми заинтересованными в проекте сторонами;

брать на себя ответственность, принимать нетривиальные решения и, при случае, терпеть неудачу;

и обладать массой других качеств.

ЛИТЕРАТУРА

Исследование операций: В 2-х томах. Пер. с англ./Под ред. Дж. Моудера, С. Элмаграби. – М.: Мир, 1981. Т.1. 712 с., ил.

Ч.Дарвин. О происхождении видов путем естественного отбора или сохранении благоприятствуемых пород в борьбе за жизнь. Сочинения, т.3. Изд-во АН СССР, Москва, 1939 г.

PMBOK guide – 2000 ed.

Основные вопросы отбора и формирования руководителей проектов

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

Знает специфику организации, отрасли и т.д.;

Достиг определенных профессиональных высот;

Имеет администраторские способности;

Имеет широкое мировоззрение, позитивный жизненный опыт, образован и эрудирован.

Список этих качеств можно продолжать и дальше, но возникает вопросы: является ли наличие перечисленных качеств достаточным для руководителя проекта, какие качества являются принципиальными, можно ли овладеть этими качествами, и если можно – то как. Можно поставить два ключевых вопроса:

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

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

В докладе мы попытаемся дать ответы на эти вопросы.

Подготовка и отбор руководителей проектов.

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

официальные – обучение специалистов в ВУЗ-ах и на специальных курсах, завершение которых удостоверяется соответствующим документом. К слушателям этой формы подготовки предъявляются обязательные требования, как при начале, так и при завершении обучения, а в ряде случаев, и по ходу самого обучения;

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

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

обучение в процессе работы – это обучение на рабочем месте при выполнении конкретного проекта, а также самообразование.

Приведенные уровни подготовки, как правило, последовательно следуют друг за другом (сначала обучение в вузе, затем повышение квалификации, получение дополнительного образования и обучение в процессе работы), но могут налагаться и пересекаться. Схематически этот процесс представлен на рисунке 2.

Рисунок 2. Структура системы подготовки и отбора руководителей проектов

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

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

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

Рисунок 3. Структура системы отбора и формирования управляющих и команды проекта

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

Привлечение кадров в сферу управления проектами

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

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

Консультируя молодых сотрудников из круга знакомых.

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

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

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

Показывая своим примером преимущества управления проектами как области профессиональной деятельности.

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

Ступени профессионального роста руководителя проектов

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

Любую деятельность человека, равно как

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

---

---