Быстрое документирование плюс обсуждение
Если разработчики активно обсуждают проект в ходе разработки, то документирование можно сделать менее формальным.
Самый замечательный трюк, позволяющий упростить документацию, это просто-напросто сфотографировать доску, на которой вы вели техническую дискуссию.
Есть и другой способ - нарисовать на бумаге архитектуру системы, диаграммы классов и т.п., а потом отсканировать рисунок и поместить его на веб. Рисовать вручную все еще гораздо быстрее, нежели с помощью примитивных программ для рисования на вебе.
Можно еще снять на видео, как два дизайнера обсуждают фрагмент архитектуры системы. Чтобы сделать это хорошо, нужно заранее позаботиться о правильном освещении и о том, чтобы обсуждение длилось не более 15 минут (видеокассету с часовой дискуссией никто не станет смотреть до конца).
Кроме того, можно написать несколько страниц текста с вкраплениями небольших фрагментов диаграммы: несколько классов модели предметной области или часть диаграммы последовательности. Лучшие описания архитектуры системы, которые мне доводилось видеть, никогда не описывали всю модель целиком. Скорее, это были небольшие группы классов, которые иллюстрировали текстовые описания дизайна системы.
Наконец, документация должна быть только "приблизительным" описанием. А именно "достаточным для того, чтобы можно было понять, у кого что спрашивать (или где посмотреть это в коде), если возникнут вопросы".
Четвертое измерение или Как обмануть Железный Треугольник
Алистэр Коуберн
Humans and Technology, 4-ое октября 2003
Перевод: , сайт maxkir.com
Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.
Конечно, процесс имеет огромное значение для проекта. При этом хороший процесс не может гарантировать, что задача будет выполнена качественно и во время, а хорошая команда программистов способна справиться с задачей, даже если процесс будет тяжелым и неуклюжим. И, тем не менее, если процесс плохой, это всегда чрезвычайно мешает работе.
Как обмануть Железный Треугольник
Когда речь заходит о руководстве проектами, мы постоянно сталкиваемся с пресловутым Железным Треугольником
В этом треугольнике три вершины, которые описывают параметры проекта: объем работ, время и ресурсы. Можете жестко задать любые две из них, но не все три. Третья величина фиксироваться не должна. В противном случае проект окажется перегружен ограничениями.
Я прямо-таки вижу, как мой читатель глубокомысленно кивает - да, конечно, мы уже знакомы с этим треугольником.
И, несмотря на это некоторые из нас все же обнаруживают, что участвуют в проектах, где все три вершины "железного треугольника" уже заданы. Например, нам говорят, что мы должны разработать определенную функциональность за 18 месяцев с бюджетом 15 миллионов. Один из моих друзей постоянно получает задания, типа "у тебя есть четыре человека и три месяца, чтобы разработать вот такую функциональность". И, пусть с небольшими поправками, мы это делаем!
Секрет в том, что существует еще одна вершина, которую пока еще не оценили по достоинству: процесс разработки.
К сожалению, в большинстве организаций процесс разработки настолько неэффективен, что можно без особого труда увеличить продуктивность работы команды на 30%, всего лишь упростив его. Так мы сэкономим время и ресурсы, что даст нам возможность завершить проект (почти) в срок и (почти) уложиться в бюджет.
Вторая часть этого "секрета" состоит в том, что это ни для кого не секрет. Руководители проектов знали и использовали его на протяжении десятилетий. Я не уверен, что этот факт описывали в литературе, но старожилы часто рассказывали мне, как они давным-давно использовали то, что сейчас называется "гибкими методологиями", чтобы выполнить невыполнимый проект в срок.
Как же обмануть Железный Треугольник?
Я нередко называю гибкие методологии "законным обманом, который приводит к победе". В любой организации есть устоявшиеся стереотипы поведения, которые только мешают работе, и на поверку оказываются совершенно лишними. Просто есть условности, о пользе которых никто не задумывается.
Вот три устоявшихся стереотипа, которые я стараюсь изменить:
Cначала нужно получить требования, а потом уже проектировать; сначала проектировать, а уже потом писать код. Лучше описывать все подробно, чем делать приблизительные наброски и обсуждать их.
Людям лучше работается в изолированных рабочих помещениях.
Давайте заменим эти правила на другие:
Сочетать различные виды деятельности и одновременно разрабатывать систему. Получить вначале ровно столько требований, сколько нужно, чтобы начать работу над архитектурой продукта (точное количество требований будет варьироваться в зависимости от конкретного проекта). Писать код на самых ранних стадиях проекта, чтобы быстрее получить отзывы о разрабатываемом варианте архитектуры.
Кратко и быстро отражать основные моменты разработки в документации и не забывать сопровождать документацию живым общением.
Дать всем возможность работать в одном помещении.
Эти три постулата можно доказать двояко. Во-первых, книгами, в которых говорится об том же, с точки зрения теории и практики разработки ПО. Во-вторых, словами руководителей успешных проектов, которые уже многие годы применяют эти правила и подтверждают их своим личным опытом.
Моя статья слишком мала, чтобы описать все стратегические и тактические приемы, которые они используют. К тому же, об этом можно прочесть в нескольких книгах: "Managing the Design Factory", "Skunk Works", "Theory of Constraints", "Lean Software Development", "Agile Software Development", и "Agile Management for Software Engineering.
Я же пока ограничусь констатацией факта: когда я вижу, что проект перегружен, то начинаю с этих трех стратегий. Впрочем, не только я, но и другие опытные руководители. Давайте теперь обратимся к их опыту.
Одновременная разработка
Итак, два приема мы уже усвоили, теперь дело за третьим - одновременной разработкой приложения.
Сначала люди, которые занимаются требованиями и работают вместе с программистами, получают ровно столько требований к системе, сколько нужно команде архитекторов, чтобы приступить к ее дизайну. Лучше всего, если один человек является одновременно и архитектором, и программистом. В худшем случае - это разные люди, которые работают бок о бок. В обоих случаях, если программирование начинается вскоре после выбора архитектуры системы, работающий (или не работающий) код даст самую верную информацию о слабых сторонах дизайна и о том, какие его части необходимо исправить сразу же, на ранних стадиях работы.
Некоторым такой стиль работы может показаться странным и даже неправильным, но я сам бывал поражен тем, что большинство команд программистов так или иначе сами приходят к использованию этой стратегии. Причина проста: им было понятно, что в противном случае их ожидает полный провал, неважно, что там полагается делать согласно официально принятому в компании процессу. Вспомните ваш последний успешный проект (или несколько проектов), и посмотрите, не использовали ли ваши программисты в разной степени эту же тактику.
Масштаб пересечения различных видов деятельности зависит от вполне конкретных вещей: "узких мест" процесса разработки, свободного времени сотрудников, нестабильности отдельных частей работы и т.п. Я обнаружил, что в разных проектах мы использовали совершенно разные стратегии одновременной разработки, в зависимости от вышеперечисленных факторов. Однако я всегда ищу, какие еще виды работ можно выполнять одновременно.
Пусть все люди работают в одном помещении
Когда люди работают в одной комнате, они постоянно находятся в пределах слышимости: можно случайно услышать информацию, которая пригодится в работе, можно задать вопрос и тут же получить на него ответ, можно услышать, как кто-то дает кому-то неправильный ответ и поправить его. При этом каждый раз экономятся время и деньги. Время, потому что иначе все отложилось бы на потом, деньги - потому что многие из неправильных и спорных вещей оказались бы задокументированы, и впоследствии пришлось бы работать уже над исправлением документации.
Некоторые из тех, кого перевели на работу в общее помещение, грустят о мирной и тихой обстановке личного офиса. Однако, как заметил один из таких людей в личной беседе: "Мне очень нравился мой личный кабинет, но если честно, еще никогда в жизни я не работал так продуктивно, как в одной комнате со своими коллегами".
Конечно, существует несколько основных правил работы в общих помещениях. Первое гласит: вся команда должна работать над одним проектом, чтобы информация, которой обмениваются люди, была полезна в работе. (Впрочем, из этого правила, как из любого другого, есть исключения. Некоторые маленькие компании с небольшой, но хорошо сработавшейся командой выигрывают даже оттого, что слышат и корректируют информацию, касающуюся разных проектов.)
Согласно второму правилу, человеку нужно иметь личное место для работы, где он бы мог, в случае необходимости, укрыться от шума. Возвращение в общую комнату означает, что он снова готов работать над общими проблемами проекта.
Разумеется, это идет вразрез с утверждением, что общее помещение для работы есть безусловное благо. Однако бывает так, что какого-то человека буквально перегружают вопросами и проблемами, и ему приходится искать себе спокойное место, где он мог бы укрыться на время от коллег. Я описал подобную ситуацию в другой статье, под названием "Тихая гавань".
Сколько это может продолжаться?
Мой коллега Джефф Пэттон (Jeff Patton), который сам использует все вышеизложенные правила, согласен с моими гипотетическими вычислениями: благодаря этим стратегическим уловкам можно сразу же сделать работу на 30% эффективнее. И тут же задал вопрос - можно ли повышать эффективность процесса разработок бесконечно, или же это единоразовая отдача?
Сначала мы полагали, что команда может обмануть "железный треугольник" только один раз. Однако, читая о повышении эффективности работ на Тойоте (Ohno, 1988), я пришел к выводу, что они занимались этим много раз на протяжении нескольких десятилетий.
Это заставляет меня думать, что мы можем обманывать "железный треугольник", по меньшей мере, немалое число раз, прежде чем он снова обретет свою неумолимую твердость. Ведь в большинстве организаций есть огромный простор для улучшений процесса работы.
"Тихая гавань и сходные стратегии управления проектами"
Интересная статья, описывающая знакомую многим ситуацию: лидером проекта является самый знающий и опытный программист, который отвечает за разработку основной функциональности системы.
Разумеется, все остальные задают ему вопросы, просят помочь с решением проблемы и т.п. Времени на реализацию своих собственных задач у него просто не остается. Выполнение проекта оказывается под угрозой, нужно срочно что-то предпринимать. При этом начальство не хочет отказываться от стратегии "все работают в одном помещении", потому что она уже хорошо себя зарекомендовала.
Лидер проекта пробует работать в смежном с основной комнатой помещении, но этот компромисс не срабатывает, потому что все программисты опять толпятся у него. Пробуют ввести "приемные часы", но эта стратегия (популярная в академических учреждениях) тут вообще не работает.
Тогда, в качестве последнего средства (сроки поджимают), лидера проекта решают на время перевести в комнату в том же здании, но тремя этажами выше. И - о чудо - за оставшиеся дни он успевает доделать все возложенные на него задачи (потому что ему никто не мешает сконцентрироваться на работе). Оставшаяся без "мозгового центра" команда справляется сама, медленнее, но все-таки справляется.
После выпуска продукта лидер проекта возвращается в общую комнату и работает там в прежнем режиме - отвечая на вопросы и разрабатывая свою часть проекта.
Вывод прост, как все гениальное: в экстремальной ситуации, когда человеку необходимо сконцентрироваться только на своей задаче, он может покидать общую комнату и укрываться на время в "тихой гавани". После он может опять посвятить себя работе в команде.
Что для этого необходимо? Во-первых, понимание и поддержка менеджмента, который пойдет на дополнительные расходы (оставшаяся команда будет работать медленнее) и заботы (отдельное помещение, коммуникация), станет вникать в особенности методологии и реализации проекта. Во-вторых, "препятствие" между общей комнатой и "тихой гаванью" должно быть "непреодолимо". В смежной комнате будет всегда толпиться народ, и никакой "тихой гавани" не получится, а вот подниматься тремя этажами выше мало кому захочется. Впрочем, некоторые фирмы, использующие подобные стратегии, "отсаживали" команды разработчиков даже в отдельные здания - даже в сравнительно небольшой статье Алистэр старается охватить проблему максимально широко, приводит много интересных примеров и библиографию.
Здесь мы приводим лишь краткий пересказ статьи. Полностью ее можно прочитать на сайте Алистэра Коуберна: ("Cone of Silence and Related Project Management Strategies").
Но, несмотря на эту поправку, общая стратегия работы в одном помещении хорошо зарекомендовала себя как в реальных, так и в исследовательских проектах.
Временные рамки
И, наконец, я должен упомянуть определение временных рамок ("timeboxing"), замечательно эффективную стратегию, о которой я пока не говорил, потому что она, как правило, "обманом" не считается.
Термин "временные рамки" имеет два разных значения, хотя в обоих случаях подразумевается определение промежутка времени, в течение которого разрабатывается некая функциональность программы. Его величина может варьироваться от одного дня до месяца (чаще всего используются промежутки длиной в неделю, две недели и месяц).
Однако есть и разница: в первом случае, требования "замораживаются" до истечения временного промежутка. Соответственно, в этих условиях команда может спокойно заниматься разработкой функциональности. Такой смысл термину "временные рамки" принято придавать в методологии Scrum (Schwaber, 2001). В другом случае, требования могут свободно меняться когда угодно, подразумевая, разумеется, что те, кто вносят изменения, имеют на это весьма веские причины. Именно так понимают этот термин приверженцы "экстремального программирования".
В тяжелой, враждебной обстановке, когда требования меняются слишком поздно, и команда не может на них отреагировать, надо переходить на "замкнутые временные рамки". Если же обстановка остается дружеской, то команда может воспользоваться преимуществом небольших оптимизаций и позволять менять требования во время фиксированного временного промежутка.
Одно из важнейших правил увеличения эффективности проекта, которое касается механизма "временных рамок", гласит:
Лучше урезать запланированную функциональность системы, но уложиться в сроки, чем тянуть (и тянуть, и тянуть) сроки, чтобы успеть завершить разработку функциональности.
На это существует ровно три причины:
Поставка продукта, какой бы урезанной ни была его функциональность, дает программистам ощущение настоящей победы, что поддерживает моральную обстановку в команде; Постоянные поставки продукта в запланированные сроки дает всем четкое представление о темпах работы команды;
Чтобы суметь вовремя поставить продукт заказчику, надо не агонизировать в поисках идеального решения проблемы, а остановиться на подходящем.
Первое даст команде ощущение уверенности, отчего со временем люди станут работать еще более эффективно. Второе поможет хорошо управлять проектом и планировать работу. И, наконец, последнее станет настоящим двигателем процесса разработки. Я сам с удивлением слушаю рассказы руководителей проектов о том, как ускорился процесс разработки лишь потому, что люди поняли необходимость принятия временно удовлетворительных решений.
Классификация подходов, методов и технологий.
В настоящий момент существует значительное количество работ, посвященных проблемам, методам и технологиям реинжиниринга ИС. Эти работы охватывают данную проблематику с различных точек зрения, рассматривая и исследуя в различной степени как проблемы концептуального уровня (иногда даже философского характера), так и конкретные методы, и инструментальные средства, предназначенные для реинжиниринга ИС.
Несмотря на наличие множества различных решений, их исследование и комплексное применение на практике бывает затруднено. Причинами возникающих трудностей следует считать:
понятие «реинжиниринг ИС» различными исследователями до сих пор трактуется по разному, существует множество близких понятий, наличие которых приводит к появлению внешне отличающихся, но по сути схожих подходов, методов и технологий;
предлагаемые решения не позиционируются в контексте других существующих решений;
решения не интегрированы на уровне методологий и технологий, большое количество методов и инструментальных средств направлено на решение отдельных локальных задач, связанных с реинжинирингом ИС;
наблюдается разрыв между решениями концептуального характера и решениями, направленными на решение конкретных прикладных задач.
Следует признать, что на множестве существующих решений (подходов, методов и технологий) отсутствует их систематизация, обеспечивающая позиционирование и определяющая взаимосвязь решений на различных уровнях рассмотрения задач реинжиниринга, в том числе, уровнях методологии и инструментальных средств.
В сложившейся ситуации целесообразным видится определение классификации, определяющей структуризацию на множестве существующих подходов, методов и технологий реинжиниринга ИС.
Так, классифицируя существующие подходы, методы и технологии, можно выделить следующие уровни рассмотрения и исследования аспектов, соотносимых с деятельностью по реинжинирингу ИС (см Рис. 4).
Рис 4. Уровни рассмотрения и исследования аспектов, соотносимых с реинжинирингом ИС.
Первый уровень включает исследования, направленные на достижение концептуального понимания деятельности по реинжинирингу ИС.
технической оценки (Reengineering Technical Assessment),
экономической оценки (Reengineering Economic Assessment),
принятия управленческих решений (Reengineering Management Decision).
Для каждого из процессов описывается его область применения, поток входящих в него работ (шагов процесса), определяются связи с другими процессами оценки. Следует признать, что потенциально эти процессы могут быть интегрированы в любой процесс разработки. Однако стоит заметить, что оценка унаследованных систем является лишь одной из задач по реинжинирингу ИС.
Еще одним примером процесса, направленного на решение локальной задачи, является итеративный процесс, определяющий следующую последовательность шагов, которые должны быть выполнены при планировании проектов реинжиниринга ИС [37]:
Определение целей, направлений деятельности организации и информационной системы.
Формирование объединенной команды, которая будет осуществлять реинжиниринг унаследованной системы.
Определение среды разработки и сопровождения, базирующейся на применении CMM (Capability Maturity Model).
Выбор стандартного множества метрик для оценки программных средств.
Анализ унаследованной системы.
Определение процесса реализации деятельности по реинжинирингу.
Разработка/Обновление стандартных средств тестирования и валидации.
Анализ средств реинжиниринга.
Обучение.
На третьем уровне рассматриваются (исследуются и разрабатываются) методы, каждый из которых направлен на решение некоторой локальной задачи, возникающей в процессе реинжиниринга ИС, например, выполнения определенного шага процесса. По сути, эти методы воплощают собой некоторые вполне конкретные решения, с которыми соотносится определенная область применения. Как правило, в проектах по реинжинирингу применятся некоторая комбинация таких методов, при этом каждый из них может стать частью методологии реинжиниринга ИС, но в отдельности таковой не является. Более того, объединение этих методов так же нельзя рассматривать в качестве методологии, поскольку между ними не определены связи, обеспечивающие их интегральную целостность.
Другими словами отсутствуют системообразующие факторы, делающие набор методов целостным образованием – системой.
С некоторой условностью все методы реинжиниринга ИС можно разделить на два класса.
Методы, относящиеся к первому классу, определены на концептуальном уровне и в целом не зависят от какой-то одной программной технологии. Так, в [2] дается обзор методов модернизации и миграции унаследованных систем. Среди всего множества рассматриваемых методов к первому классу относятся метод репликации баз данных и основанный на объектно-ориентированном подходе метод построения оболочек для компонентов унаследованной системы (object – oriented wrapping), методы «белого» и «черного» ящика модернизации системы. Другими представителями данного класса являются: методы оценки вариантов реинжиниринга ИС [9, 11, 33], метод планирования миграции программных средств [8], методы извлечения знаний о существующей системе [3, 4, 17], методы трансформации (реконструкции) архитектуры ИС [3, 7, 19, 21], методы автоматизации реинжиниринга программ [6, 23] и т.д. В целом следует считать, что область применения таких методов, как правило, характеризуется некоторым классом программных технологий. А для применения в реальных проектах каждый из них адаптируется с учетом используемых в проекте технологий и инструментальных средств.
Отдельным направлением исследований, относящимся к данному классу и получившим развитие в последние годы, является исследование и разработка образцов реинжиниринга ИС [26-30, 36]. Каждый из образцов реинжиниринга ИС нацелен на решение некоторой типовой задачи (проблемы), которая сопровождает деятельность по реинжинирингу ИС. Не смотря на некоторые отличия, авторы в целом придерживаются единого подхода к описанию таких образцов. Так, в [26] определяется следующий шаблон описания.
Имя образца.
Цели применения.
Область приложения.
Мотивация к применению.
Структура системы до и после применения образца.
Процесс применения образца.
Обсуждение образца.
Особенности, зависящие от языка программирования.
Стоит заметить, что хотя последний из разделов шаблона «привязывает» шаблон к определенной среде реализации, языкам программирования, все же каждый из образцов представляет некоторое концептуальное решение проблемы. Подробную информацию об образцах реинжиниринга можно найти в книге «Object-Oriented Reengineering Patterns» [27].
В отличие от первого класса, методы второго изначально ориентированы на использование определенных программных технологий. Ко второму классу относятся так же адаптации методов из первого класса. Здесь методы в наибольшей степени приспособлены к их непосредственному (прямому) применению в конкретных проектах. Примерами методов данного класса следует считать [2]: методы интеграции с использованием CGI, методы интеграции на основе технологии XML, метод построения оболочек для компонентов унаследованной системы с использованием технологии CORBA.
И наконец, четвертый уровень включает исследование и разработку инструментальных программных средств, автоматизирующих применение подходов, методов и технологий, рассматриваемых на предыдущих уровнях. Следует признать, что в настоящий момент таких средств существует большое количество, среди которого выделяются средства [3, 4, 6, 23, 31, 32, 35]:
переноса приложений написанных на устаревших языках на современные языки и платформы (например, с языков PL/1, Кобол на языки C++, Java, Visual Basic);
средства интеграции унаследованных приложений, к примеру, на основе метода построения оболочек для компонентов унаследованной системы;
средства автоматизированного извлечения данных из унаследованных систем;
средства автоматизированного извлечения знаний об унаследованных системах;
средства оптимизации (реструктуризации) унаследованных систем при их переносе на современные языки и платформы (как на уровне программного кода, так и на уровне архитектуры ИС);
различные средства анализа программного кода.
Полезная классификация инструментальных средств дается в [31]. В рамках этой классификации выделяются такие типы средств, как
реинжиниринга бизнес процессов;
преобразования имен данных;
реинжиниринга данных (БД);
прямого инжиниринга;
преобразования форматов;
реструктуризации;
обратного проектирования;
трансляции исходного кода;
и др.
В этой же работе авторами приводятся характеристики инструментальных средств реинжиниринга ИС. Для каждого из них специфицируется имя программного продукта; требования к аппаратной и программной платформе; координаты компаний – поставщиков; поддерживаемые языки программирования, СУБД, платформы; принадлежность к тому или иному типу средств.
Осуществляя классификацию и исследование существующих подходов, методов и технологий реинжиниринга ИС, дополнительно к уже выделенным уровням, следует добавить еще два, являющихся по своей природе интегральными. Это уровень методологии и уровень технологии реинжиниринга ИС. Первый из них обеспечивает целостное рассмотрение и применение подходов и методов без учета среды их реализации, специфики конкретных проектов. Это соответствует интеграции первых трех уровней, причем на третьем уровне в сферу рассмотрения, в первую очередь, попадают методы первого класса. Уровень технологии обеспечивает адаптацию (конкретизацию) методологии реинжиниринга ИС с учетом среды реализации, специфики конкретных проектов посредством применения методов и инструментальных средств, соответствующих третьему и четвертому уровням. При этом в отличие от методологии, на третьем уровне, прежде всего, рассматриваются методы второго класса.
Следует признать, в процессе проводимых авторами настоящей статьи исследований не было обнаружено целостных методологий и технологий реинжиниринга ИС, соответствующих уровню проработки и области охвата RUP [24, 25]. В наибольшей степени эту проблема исследуется в [1, 8, 15, 33]. В тоже время, в [1] предлагается лишь каркас, определяющий основной ход работ, в [8] даются рекомендации по выполнению основных видов деятельности по реинжинирингу. В [33] определяются лишь процессы оценки унаследованных систем, а в [15] основное внимание уделяется вопросам технического характера, при этом основной акцент сделан на решение проблем интеграции систем, в то время как методы анализа унаследованной системы практически не рассматриваются.
Представленный подход к классификации обеспечивает систематизацию на множестве существующих подходов, методов и технологий реинжиниринга ИС. В качестве его основных областей применения следует рассматривать:
оценку состояния в области методологического и технологического обеспечения реинжиниринга ИС;
адаптацию и разработку методологий и технологий реинжиниринга ИС.
В завершении данного раздела стоит отметить, что возможны и другие полезные подходы к систематизации методов и технологий реинжиниринга ИС. Так, предлагаемые и исследуемые различными авторами процессы реинжиниринга, как правило, охватывают систему в целом, в то время как методы могут соотноситься с некоторыми ее составляющими, с отдельными шагами процесса. Последний факт обуславливает возможность классификация многих методов:
по объектам применения (например, в зависимости от их типа (компонент пользовательского интерфейса, компонент данных, вычисляющий компонент (компонент бизнес - логики)));
по видам деятельности процесса реинжиниринга (методы извлечения знаний о существующих ИС (методы обратного проектирования), методы оценки (анализа) существующих ИС и т.д.).
Литература.
John Bergey, William Hefley, Walter Lamia, Dennis Smith A Reengineering Process Framework, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1995.
Santiago Comella-Dorda, Kurt Wallnau, Robert C. Seacord, John Robert A Survey of Legacy System Modernization Approaches, Software Engineering Institute (Technical Note CMU/SEI-200-TN-003, 00tn003.pdf), Pittsburgh, 2000.
Rick Kazman, S. Jeromy Carriere Playing Detective: Reconstructing Software Architecture from Available Evidence. Technical Report CMU/SEI-97-TR-010. Pittsburgh, 1997.
Rick Kazman, S. Jeromy Carriere View Extraction and View Fusion in Architectural Understanding, Proceedings of the Fifth International Conference on Software Reuse (ICSR), June, 1998, Victoria, BC.
Кротов А.А. и Лупян Е.А. Обзор методов реструктуризации и интеграции информационных систем, http://d902.iki.rssi.ru/students/alekro/Dissertation/Papers/Reengineering/my_review.html
"Автоматизированный реинжиниринг программ" Сборник статей под ред. А.Н.Терехова и А.А.Терехова Издательство С.-Петербургского университета, 2000.
Guo G. Y., Atlee J. M., Kazman R. A Software Architecture Reconstruction Method, Department of Computer Science, University of Waterloo, Software Engineering Institute, Carnegie Mellon University.
John Bergey, Dennis Smith, Nelson Weiderman DoD Legacy System Migration Guidelines, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, September 1999.
John Bergey, Dennis Smith, Nelson Weiderman, Steven Woods Options Analysis for Reengineering (OAR): Issues and Conceptual Approach, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, September 1999.
Weiderman N., Nelson H., Bergey John K., Smith Denis B., & Tilley Scott R. Approaches to Legacy System Evolution, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213, 1997 (CMU/SEI-97-TR-014)
Ransom J., Sommerville I., & Warren I. A Method for Assessing Legacy Systems for Evolution, Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering (CSMR98), 1998
Основное содержание реинжиниринга ИС и его место в ЖЦ ИС.
Следующим шагом на пути исследования подходов, методов и технологий реинжиниринга ИС следует считать определение основного содержания деятельности по реинжинирингу ИС, места реинжиниринга в ЖЦ ИС.
Так, в [1] авторы придерживаются следующей позиции при определении границ деятельности по реинжинирингу, и, как следствие, места реинжиниринга в ЖЦ ИС.
Утверждается, что реинжиниринг ИС занимает промежуточное местоположение по отношению к разработке и сопровождению ИС. При этом сопровождение ИС рассматривается как деятельность, предусматривающая выполнение изменений, направленных на коррекцию, усовершенствование и адаптацию ИС, а разработка ИС как деятельность, включающая реализацию новых возможностей, добавление новой функциональности, осуществление таких существенных улучшений, как переход на использование новых компьютеров, внедрение новых информационных технологий. Авторами правомерно утверждается, что реинжиниринг характеризуется деятельностью, как по сопровождению, так и по разработке ИС. При этом эти два вида деятельности в контексте реинжиниринга ИС могут существенно перекрываться.
В отличие от [1], работа [2] посвящена вопросам модернизации унаследованных информационных систем. В ней делается обзор различных методик модернизации унаследованных систем, определяется роль модернизации систем в процессе управлениях их эволюцией. Утверждается, что коммерческий рынок предлагает разнообразные решения проблемы модернизации унаследованных систем, которая становится все более актуальной. В сложившейся ситуации понимание преимуществ и слабых мест каждой такой методики является чрезвычайно важным, поскольку обуславливает выбор правильного решения, и как следствие успех деятельности по модернизации системы.
В контексте исследований, связанных с эволюцией ИС, авторами выделяются деятельности по сопровождению, модернизации и замещению ИС.
Определяется, что сопровождение представляет собой инкрементальный итеративный процесс, в рамках которого выполняются малые изменения в системе, не затрагивающие структурной организации системы (архитектуры системы).
В отличие от сопровождения модернизация характеризуется как деятельность, которая предусматривает значительные изменения существующей системы (в том числе в ее структуре), но не ее утилизацию или замещение новой системой.
И, наконец, замещение рассматривается как процесс, который заключается во внедрении новой системы, способной полностью заменить существующую ИС. Замещение обычно применяется к системам, которые недокументированны, устарели или не расширяемы, расходятся с требованиями бизнеса и для которых модернизация невозможна или экономически не выгодна.
Определяя место этих видов деятельности в контексте ЖЦ ИС, авторы рассматривают следующую последовательность их выполнения (см Рис. 1).
Рис. 1 Жизненный цикл ИС.
Первоначально, осуществляется разработка (построение) ИС. Далее выполняется деятельность по ее сопровождению. В процессе сопровождения возникает необходимость в реструктуризации системы и как следствие выполняется деятельность по ее модернизации. После этого снова осуществляется деятельность по сопровождению системы. В тот момент, когда ИС перестает удовлетворять заказчика, осуществляется ее замещение на новую систему и последовательность выполняемых видов деятельности повторяется. Безусловно, в реальной жизни может возникать и другая последовательность, когда, сразу, не прибегая к модернизации, осуществляется замещение одной ИС другой. Однако общий подход к последовательности выполнения сопровождения, модернизации и замещения останется неизменным.
Приводимые в [2] виды деятельности основаны на таксономии, вводимой в [16]. В отличие от предыдущей работы, в [16] в качестве базового понятия используется именно «реинжиниринг», а вводимая таксономия рассматривается как множество видов деятельности, соотносимых с реинжинирингом ИС. При этом применительно к унаследованным ИС выделяются соответственно деятельности по их оценке, сопровождению, трансформации, замещению, а так же смешанные стратегии, предусматривающие совместное выполнение перечисленных ранее видов деятельности.
Обеспечивая концептуальное понимание процесса реинжиниринга ИС, в ряде работ [1, 9] определяются основные виды деятельности (фазы) соотносимые с этим процессом.
Так, в [1] рассматриваются следующие основные фазы:
оценки показателей проекта по реинжинирингу, в том числе характеристик унаследованной информационной системы (фаза оценки);
анализа решений по реинжинирингу, в том числе принятие решения о необходимости проведения работ по реинжинирингу или сопровождению/разработке ИС;
осуществления реинжиниринга (выполнения работ по реинжинирингу);
внедрения системы, трансформированной в результате проведения реинжиниринга.
Другой подход к определению деятельности по реинжинирингу базируется на так называемой модели «подковы» [9, 21].
В основу данной модели положены следующие процессы (виды деятельности), соотносимые с реинжинирингом ИС:
анализ существующей системы, основанный на одном или более ее логических описаний;
трансформация этих логических описаний в новое, улучшенное логическое описание системы.
разработка новой системы, основанной на новых логических описаниях системы.
Эти три основных процесса соединяются в модели в виде «подковы» (см Рис. 2).
Рис.2 Модель «подковы».
Первый процесс (Architecture Recovery) предусматривает восстановление архитектуры существующей системы посредством извлечения на основании исходного кода характеризующих ее артефактов. Полученная архитектура анализируется на предмет соответствия требованиям к изменяемости, надежности, защищенности и так далее.
Второй процесс (Architecture Transformation) заключается в трансформации (реинжиниринге) восстановленной архитектуры к желаемой новой архитектуре. Полученная в результате трансформации новая архитектура оценивается с позиции ее качества с учетом накладываемых на нее организационных и экономических ограничений.
И, наконец, третий процесс (Architecture-based Development) включает деятельность по разработке системы, соответствующей новой архитектуре. Здесь решаются вопросы декомпозиции элементов системы по пакетам, осуществляется выбор стратегий взаимодействия элементов/компонентов системы.
В рамках данного процесса так же обеспечивается интеграция в новую систему артефактов унаследованной системы, например, посредством переписывания части унаследованного кода и/или применения технологии построения оболочек для компонентов унаследованной системы.
С моделью «подкова» соотносится три уровня, на каждом из которых может осуществляться трансформация существующей системы.
Представление на уровне структуры кода (Code-Structure Representation) включает программный код, а так же такие артефакты, как абстрактные синтаксические деревья и графы потоков (flow graphs), получаемые на основании выполнения различного рода аналитических операций (например, разбора кода). Текстуальный перевод, а так же перевод на основе синтаксических деревьев являются примерами трансформации системы на этом уровне.
В отличие от предыдущего уровня, представление на уровне функциональности системы (Function-Level Representation) предусматривает определение связей между функциями программ (например, последовательности вызовов), данными (как частный случай, связей между сущностями данных, соотношений данных и функций) и файлами (к примеру, распределение функций и данных по файлам). Трансформация системы на данном уровне осуществляется на основании пересмотра функциональности системы и заключается, например, в переходе от функционального подхода к объектному подходу к анализу и проектированию, в переходе от реляционной БД к объектной БД.
На архитектурном уровне артефакты предыдущих уровней, объединяются в подсистемы в терминах архитектурных компонентов архитектуры ИС. Трансформация системы на этом уровне предусматривает коренные изменения в структуре программы, в том числе в части применения основных образцов взаимодействия компонентов: типов программных компонентов, используемых соединителей (connectors), вариантов декомпозиции функциональности, образцов управления и обмена данными времени выполнения.
Согласно модели «подкова» трансформация системы, в зависимости от ситуации, может осуществляться на каждом из представленных уровней, при этом более низкий уровень поддерживает трансформацию на более высоком уровне.
Следует признать, что модель «подкова» находит широкое применение в рамках деятельности, связанной с реинжинирингом ИС. Так, в [20] на ее основе определяются требования и основной каркас для интеграции инструментальных средств реинжиниринга на архитектурном уровне и уровне программного кода. С учетом соотносимых с ней процессов и уровней представления, осуществляется расширение модели CORUM (Common Object-based Reengineering Unified Model). Эта модель, в свою очередь, разрабатывалась:
для представления требуемой для систем управления на основе программного кода (Code-based Management System) информации о программных средствах;
для обеспечения интероперабельности между системами данного класса (в том числе между средствами реинжиниринга программ на уровне программного кода).
В контексте вводимых расширений в этой же работе для модели «подкова» определяется семантическая модель, обеспечивающая на основании формулируемых унифицирующих свойств семантическую связь между архитектурным уровнем и уровнем программного кода.
Подход, предложенный в [34-36], очень близок к подходу, основанному на модели «подкова». Характеризуя жизненный цикл реинжиниринга ИС, авторы определяют следующие шаги процесса реинжиниринга:
анализ требований для выявления конкретных целей реинжиниринга унаследованной системы;
восстановление модели, в том числе документирование и понимание структуры унаследованной системы;
выявление проблем, связанных с унаследованной системой;
анализ проблем, включающий выбор архитектуры, позволяющий устранить обнаруженные в унаследованной системе дефекты;
реорганизация, включающая выбор и применение оптимального подхода трансформации унаследованной системы;
распространение изменений.
В отличие от предыдущих работ, в [10, 13] деятельность по реинжинирингу рассматривается в качестве одной из форм деятельности по эволюции унаследованных ИС, когда, требуется более сильнодействующее «лекарство» для «лечения» ИС, нежели серия локальных инкрементальных изменений [13].
Так, в [13] описывается каркас (enterprise framework), характеризующий:
глобальную среду, в которой осуществляется эволюция системы;
действия, процессы и рабочие продукты (артефакты), которые сопровождают деятельность по эволюции системы.
Авторами подчеркивается, что помимо технических вопросов, связанных с эволюцией унаследованных ИС, существует так же множество организационных вопросов. Например, «Как планировать эволюцию большой сложной системы, включая ее реинжиниринг?», «Какие существуют критичные факторы успеха эволюции системы?», «Как оценить, что люди, осуществляющие эволюцию системы, на правильном пути?». Кроме этого, важным является необходимость учета стратегических, организационных, и других аспектов бизнеса, влияющих на эволюцию унаследованной ИС.
Поэтому основной целью создания каркаса (enterprise framework) следует считать необходимость оценки среды, в рамках которой осуществляется эволюция унаследованной ИС, необходимость обеспечения понимания широкого спектра вопросов, как технического, так и управленческого характера, которые соотносятся с эволюцией унаследованных ИС. Важнейшим здесь становится выявление факторов, определяющих успех деятельности по эволюции ИС, а так же разработка согласованного множества технических и управленческих инструкций (действий), требуемых для эффективного планирования, оценки и управления инициативами по эволюции систем.
Отражая применительно к эволюции системы пространство проблем и пространство решений, предлагаемый в [13] каркас включает такие элементы, как организация, проект, унаследованная система, инженерия систем и программных средств, технологии, целевая система. Между этими элементами определяется связь. При этом для каждого из них приводится список вопросов (checklists), позволяющий охарактеризовать (исследовать и оценить) интересующий элемент.
Следует признать, что положенная в основу каркаса концепция является расширением концепции разработки ИС с учетом деятельности по внедрению, повседневных операций и деятельности по сопровождению.
Каркас может быть использован для выполнения следующих видов деятельности:
исследование и анализ пространства проблем и пространства решений в контексте инициатив по эволюции системы;
разработка руководств по составлению стратегических и тактических планов по реинжинирингу унаследованных систем;
выявление технологических вопросов и потенциальных проблем на протяжении всего пути по эволюции систем;
рецензирование планов, ранжирование (приоритезация) технических вопросов, разработка рекомендаций по улучшениям процессов эволюции систем и результатов их выполнения (рабочих продуктов).
Общий подход к использованию каркаса представлен на Рис. 3.
Рис. 3 Общий подход к использованию каркаса.
В рамках подхода выделяются две значительные составляющие: основная фаза и фаза эволюции. Основная фаза сфокусирована на таких элементах, как организация, проект и унаследованная система. Фаза эволюции концентрируется на целевой системе, инженерии систем и программных средств, технологиях, используемых для построения целевой системы. Другими словами первая фаза сфокусирована на пространстве проблем, а вторая на пространстве решений.
В [10] авторами предлагается комплексный, основанный на рассмотренном ранее каркасе, подход к эволюции систем, который определяется в контексте унаследованных систем и современных программных технологий.
В основу подхода положены следующие положения (принципы):
различие между эволюцией систем и сопровождением программных средств;
использование описанного ранее каркаса (enterprise framework) при поддержке принятия решений в процессе эволюции системы;
достижение технического понимания систем на высоком уровне абстракции;
применение технологий распределенных объектов, технологии «wrapping» [10] для эволюции системы;
применение «net-centric» [10] вычислений для эволюции системы.
Определяя различие между сопровождением программных средств и эволюцией систем в части реинжиниринга ИС, авторы рассматривают сопровождение как «мелкозернистую», «краткосрочную» деятельность, направленную на планирование и внесение локализованных изменений.
При сопровождении структура (архитектура) системы остается относительно неизменной, а требуемая «порция» вносимых за определенный промежуток изменений, как правило, связана с изменением какого-либо одного требования к системе. Такие изменения, обычно, не сопровождаются существенным изменением значений характеристик и атрибутов качества программных средств.
В отличие от сопровождения, эволюция систем рассматривается как «крупнозернистая», «высокоуровневая», форма изменений на уровне структуры (архитектуры) системы. Вносимые в процессе эволюции изменения, приводят к изменениям значений атрибутов качества, что, как правило, существенно упрощает сопровождение систем. Для этого при внесении изменений в структуру системы могут использоваться стратегии «снизу вверх» и «сверху вниз», применение которых основано на ревизии программного кода, восстановлении описания архитектуры унаследованной системы, проектировании новой структуры, новой формы документации и т.д.
Авторами подчеркивается, что эволюция позволяет адаптировать систему сразу с учетом большого количества выдвигаемых к ней требований (включая приобретение новых возможностей), что в конечном итоге увеличивает стратегическую и экономическую значимость программных средств. При этом акцент смещается от понимания программ к пониманию систем, от сопровождения к эволюции и миграции, от стратегий «снизу вверх» к стратегиям «сверху вниз».
В отличие от рассмотренных ранее работ, в [15] основное внимание уделяется исследованию и решению технических проблем, связанных с миграцией унаследованных систем. Характеризуя понятие «миграция ИС» в данной работе выделяются отдельно эволюция, сопровождение и миграция ИС. Основываясь на том факте, что объектом эволюции и сопровождения является унаследованная ИС, а объектом миграции как унаследованная, так и новая (целевая) системы, авторы разделяют миграцию и другие процессы ЖЦ ИС. При этом миграция рассматривается как деятельность, которая начинается с унаследованной ИС и заканчивается сопоставимой целевой ИС.
В основу предлагаемого авторами подхода положена декомпозиция структуры системы на компоненты пользовательского интерфейса, компоненты – приложения и компоненты управления базами данных. При этом в качестве основных инкрементально выполняемых шагов миграции выступают:
анализ унаследованной ИС;
декомпозиция структуры унаследованной ИС;
проектирование интерфейсов (пользовательских и системных) целевой системы;
проектирование приложений (функциональной логики) целевой системы;
проектирование базы данных целевой системы;
развертывание среды, требуемой для эксплуатации и сопровождения целевой системы;
создание и развертывание необходимых шлюзов;
миграция унаследованных данных;
миграция унаследованных приложений (компонентов, реализующих функциональную логику);
миграция унаследованных интерфейсов (пользовательских и системных);
переход к использованию целевой системы.
Понятие «реинжиниринга ИС».
Сразу следует признать, что в настоящий момент понятие «реинжиниринг ИС» не является повсеместно устоявшимся. Как следствие довольно часто возникает определенная терминологическая путаница. Авторами исследуются одни и те же проблемы, подходы, методы и технологии их решения, однако в качестве базовых понятий, наряду с «реинжинирингом ИС» [1, 9, 16, 20] употребляются «эволюция ИС» [10, 13], «миграция ИС» [15], «модернизация ИС» [2], «реструктуризация ИС» [5].
Нельзя отрицать, что деятельность по миграции ИС имеет определенную специфику (окраску) по отношению к деятельности по модернизации ИС. Однако, принимая во внимание определение реинжиниринга ИС, приводимое в [1]:
«Реинжиниринг представляет собой систематическую трансформацию существующей системы с целью улучшения ее характеристик качества, поддерживаемой ею функциональности, понижения стоимости ее сопровождения, вероятности возникновения значимых для заказчика рисков, уменьшения сроков работ по сопровождению системы»,
становится очевидным, что и миграция, и модернизация ИС являются частью деятельности по реинжинирингу ИС. Как результат, подходы, методы и технологии миграции, модернизации, эволюции ИС, следует считать частью методологического и инструментально - технологического обеспечения процесса реинжиниринга ИС.
Такой взгляд на реинжиниринг ИС согласуется с таксономией, вводимой в ряде работ [34, 36, 38-40]. В этих работах авторами делается попытка выстроить систему понятий, соотносимых с данным видом деятельности. Так, в [38] реинжиниринг ИС определяется как «исследование (изучение, обследование) и перестройка исходной системы с целью ее воссоздания в новой форме с последующей реализацией этой новой формы. Далее, в контексте деятельности по реинжинирингу вводятся и определяются такие важные понятия, как
прямой инжиниринг (Forward engineering);
редокументирование (Redocumentation);
рефакторинг (Refactoring);
реструктуризация (Restructuring);
переориентация (Retargeting);
обратный инжиниринг (обратное проектирование) (Reverse engineering);
сопровождение программных продуктов (Software maintenance);
трансляция исходного кода (Source Code Translation);
и т.д.
Перечисленные понятия раскрывают понятие «реинжиниринг ИС», а соотносимая с ними деятельность рассматривается либо как одна из форм реинжиниринга ИС, либо как подпроцесс процесса реинжиниринга. Определения этих и других понятий приводятся в приложении к данной статье в глоссарии понятий и терминов. При этом в тех случаях, когда проявлялись отличия в определении того или иного понятия, в глоссарий включались альтернативные варианты определения, а при необходимости, и поясняющие определение комментарии.
Понятие «реинжиниринга ИС», его содержание и место в ЖЦ ИС.
Существует ряд работ [1, 2, 5, 9, 10, 13, 15, 16, 20, 34-36], в которых в различной степени определяется соотносимая с реинжинирингом ИС деятельность, выявляется и исследуется место реинжиниринга в ЖЦ ИС.
А. Глоссарий понятий и терминов.
Реинжиниринг бизнес-процессов (Business Process Reengineering) Фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность [40]. Рационализация имен данных (Data name rationalization (DNR)) Унификация именования данных, являющаяся специальным случаем реинжиниринга данных. Заключается во введении унифицирующих соглашений по именованию во всех программных системах [40]. Реинжиниринг данных (Data Reengineering) Выполнение всех функций реинжиниринга, соотносимых с исходным кодом, но применительно к файлам данных [40]. Восстановление результатов проектирования (Design recovery) Подмножество обратного инжиниринга, в котором знание проблемной области, внешняя информация, логические выводы или нечеткие суждения принимаются во внимание при обследовании исходной системы. Целью восстановления результатов проектирования является выявление значимых высокоуровневых абстракций, в дополнение к тем, которые были получены в процессе непосредственного исследования (изучения) системы [38]. Прямой инжиниринг (Forward engineering) Традиционный процесс перехода от высокоуровневых абстракций и логического, независящего от реализации проектирования к физической реализации системы [38]. Представляет собой переход от требований к высокоуровневому проектированию, и далее к низкоуровневому проектированию и реализации [36]. Представляет собой множество видов деятельности по инжинирингу системы, на вход которым для производства новой целевой системы поступают продукты и артефакты, производные от унаследованных программных средств, и новые требования [40]. Комментарий
Основное отличие прямого инжиниринга от реинжиниринга заключается в том, что в случае реинжиниринга «стартуют» от существующей реализации (существующей системы). Основное отличие прямого инжиниринга от инжиниринга в целом заключается в том, что на вход прямого инжиниринга поступают результаты реинжиниринга [40].
Процесс извлечения информации из существующей программной системы [36]. В общем случае обратное проектирование применяют для извлечения информации на высоком уровне абстракции, например информации уровня проектированию на основе программного кода. Сопровождение программных продуктов (Software maintenance) Модификация программного продукта после его поставки в целях исправления ошибок, улучшения производительности и других атрибутов качества, или адаптации продукта к изменениям окружения (внешней среды) [39]. Трансляция исходного кода (Source Code Translation) Трансляция исходного кода с одного языка программирования на другой или с одной версии в другую на том же самом языке программирования [40]. Инжиниринг систем (Systems Engineering) Высокоуровневый процесс инжинирии систем, направленный на достижение соответствия системы всем выдвигаемым к ней требованиям [40].
Далее в настоящей работе при исследовании существующих решений употребляется оригинальная терминология, предлагаемая авторами работ. При этом в качестве рабочего варианта используется определение реинжиниринга ИС, приводимое в [1].
в различных организациях позволяют сделать
Результаты исследований состояния информатизации в различных организациях позволяют сделать вывод, что в настоящий момент большинство из них уже имеет некоторые информационные системы (ИС). Эти ИС в различной степени автоматизируют процессы, протекающие в организациях.
Исследования проектов информатизации, и, в первую очередь, проектов разработки ИС так же показывают, что создание новой информационной системы в большинстве случаев предусматривает изменение состояния существующих ИС. Типичными стали проекты:
по разработке новых ИС и их интеграции с существующими ИС;
по разработке новых ИС с целью замены существующих ИС;
по модернизации (наращиванию функциональности, развитию) существующих ИС.
По сути, сегодня можно говорить, что эра, когда разработчики ИС приходили в организацию и начинали проекты информатизации «с нуля», прошла. Наступает время проектов по систематической трансформации существующих ИС или эра реинжиниринга ИС.
Следствием сложившейся ситуации становится объективная потребность в исследовании, пересмотре и переосмыслении существующих подходов, методологий и технологий разработки ИС, что, в свою очередь, может потребовать их модернизации, а возможно, и разработки новых решений.
Ситуация осложняется тем, что в настоящий момент различными исследователями и практиками понятие реинжиниринга ИС трактуется по разному. Во многом это обусловлено необычайно широким спектром задач по реинжинирингу, с которыми приходится сталкиваться в реальных проектах.
Сегодня в мире существует большое количество подходов, методов и технологических решений, напрямую или косвенно соотносимых с деятельностью по реинжинирингу ИС. Однако они не интегрированы на уровне методологий (процессов разработки). Как результат, можно наблюдать наличие огромного количества методологий, где основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие «стройных» методологий, целью создания которых являлось бы комплексное, целостное решение задач реинжиниринга ИС.
В настоящей статье исследуются существующие подходы, методы и технологии реинжиниринга ИС, предлагается подход к их классификации. На основании результатов исследований и вводимой классификации дается оценка текущего состояния в данной области.
Заметим, что в процессе написания статьи не ставилась цель исследовать все решения в области реинжиниринга ИС, представить детальную информацию по каждому из них. В то же время авторами была предпринята попытка рассмотреть основные подходы, методы, технологии и инструментальные средства, которые характеризуют состояние дел в данной области. Детальную информацию об интересующих решениях можно найти в литературе, ссылки на которую представлены в конце статьи, а так же на следующих Web – сайтах:
http://www.informatik.uni-stuttgart.de/ifi/ps/reengineering/
http://www.iam.unibe.ch/
http://www.stsc.hill.af.mil/reng/
http://www.sei.cmu.edu/reengineering/index.html
http://www.tcse.org/revengr/
и вводимой классификации подходов, методов
На основании проведенных исследований и вводимой классификации подходов, методов и технологий реинжиниринга ИС, становится возможным охарактеризовать текущее состояние в области его методологического и технологического обеспечения.
Так, несмотря на наличие большого количества работ, охватывающих данную проблематику с различных точек зрения, следует признать, что:
понятие «реинжиниринг ИС» различными исследователями до сих пор трактуется по разному, существует множество близких понятий, наличие которых приводит к появлению внешне отличающихся, но по сути схожих подходов, методов и технологий;
существующие методы и технологии не позиционируются в контексте других существующих решений, не интегрированы на уровне методологий и технологий;
наблюдается разрыв между решениями концептуального характера и решениями, направленными на решение конкретных прикладных задач;
отсутствует четкая взаимосвязь между методами/технологиями реинжиниринга и методологиями разработки ИС «с нуля».
В сложившейся ситуации актуальной задачами становятся:
унификация, а возможно, и стандартизация понятия «реинжиниринг ИС», других связанных с ним понятий;
разработка целостных методологий реинжиниринга ИС;
разработка средств адаптации методологий реинжиниринга ИС в реальных проектах;
создание инструментальных средств, обеспечивающих комплексное решение задач по реинжинирингу ИС;
интеграция методологий разработки «с нуля» и методологий реинжиниринга, в том числе и на уровне поддерживающих их инструментальных средств.
Designing for FAILURE - ключ к успеху?Беседа с Брюсом Линдсеем
Прокомментировать>>
Перевод: Сергей Кузнецов
Оригинал: A Conversation with Bruce Lindsay, ACM Queue, Vol. 2, No. 8 - November 2004.
Брюс Линдсей – это одна из легендарных фигур в истории баз данных. Он появился в IBM на закате проекта System R, и сразу привлек внимание в качестве соавтора многих замечательных статей. Но, прежде всего, он системный архитектор и программист. Именно под его архитектурным руководством был выполнен один из наиболее интересных проектов в области баз данных Starburst. В предлагаемом вашему вниманию интервью он говорит, в основном, не о базах данных, хотя все время имеет их в виду. Он говорит о том, как следует разрабатывать программные системы, чтобы добиться их общей надежности в условиях ненадежности компонентов, программистов, языков программирования и окружающей среды. Замечательно, что это интервью у Линдсея брал не менее легендарный персонаж из истории операционной систем Unix Стив Борн, создавший первый язык и интерпретатор Shell. Приятного и полезного вам чтения. Сергей Кузнецов
В конце 1980-х гг. он участвовал в разработке протокола DRDA (Distributed Relational Database Architecture, архитектура распределенной реляционной базы данных), а позже являлся главным архитектором Starburst, расширяемой системы баз данных, которая со временем превратилась в оптимизатор запросов и интерпретатор для DB2 на платформах Unix, Windows и Linux.
Линдсей разработал концепцию экстендеров баз данных, в которых мультимедийные данные – изображения, голосовые и видеоданные – трактуются как объекты, являющиеся расширениями стандартной реляционной базы данных, и эти данные можно запрашивать с использованием стандартного SQL (Structured Query Language). Сегодня он по-прежнему глубоко погружен в работу в лаборатории управления данными в Исследовательском центре IBM в Алмаден, участвуя в создании продуктов управления данными следующего поколения.
Стив Борн: Почему бы нам не начать с той мысли, что нельзя избавиться от ошибки, пока ее не обнаружишь?
Брюс Линдсей: Давайте немного поразмышляем над тем, как возникают ошибки. Они возникают на всех уровнях системы, и их причины могут простираться от воздействия альфа-частиц, разряжающих конденсаторы основной памяти, до пожаров, наводнений или террористических актов, разрушающих вычислительные системы целиком. Все делается неправильно, начиная с грубых промахов в логике программирования и заканчивая данными, поступающими не с того сектора диска. Нужно производить разработку систем с учетом возможности отказов на всех возможных уровнях системы, от уровня электронных схем до уровня подсистем, таких как СУБД или файловая система, и даже до уровня самих прикладных программ.
«Engineering for failure (разработка с учетом возможности отказа)» – это, возможно, плохое выражение, но в действительности это именно то, что требуется для обеспечения надежной и заслуживающей доверия обработки информации.
СБ: Безусловно верно, что при написании кода и разработке систем в голове должна сидеть мысль: «А что здесь может поломаться?». Причин может быть множество, и возможные линии поведения зависят от типа приложения или программного обеспечения. При написании программы типа Microsoft Word они совсем не те, что при разработке кардиомонитора.
БЛ: В случае кардиомонитора вы обязаны поддерживать работу сердца, а в случае Microsoft Word можно всего лишь выдать пользователям «синий» экран, к которому все привыкли.
СБ: Но в случае кардиомонитора вряд ли разумно спрашивать пользователей, хотят ли они поддерживать работу сердца, поскольку ответ очевиден, а в случае Word иногда стоило бы спросить пользователей, как поступать в создавшейся ситуации.
БЛ: Иногда можно спрашивать пользователя, хотя лучше было бы спросить подсистему, что она собирается сделать для самовосстановления, или прекратить ее работу в зависимости от ситуации.
СБ: Вы действительно противопоставляете отказы системы ошибкам пользователей?
БЛ: Я не считаю «отказами» ошибки пользователей, такие как ввод неверных данных. Это нормальное явление. Вряд ли неправильное написание go to вызовет ошибку в работе компилятора. Такие вещи являются ожидаемыми.
СБ: Что же такое, по Вашему мнению, ошибка?
БЛ: Ошибка возникает в каждом случае, когда некоторый используемый компонент не выдает ожидаемого результата, будь то обращение к основной памяти, которое не может быть выполнено из-за проблем с контролем четности, безрезультатный обмен данными с диском или вызов подпрограммы, в которой возникает исключительная ситуация. «Меня попросили выполнить действие X, а я этого не сделал.»
Хороший принцип разработки состоит в следующем: либо делайте то, что вас просят, либо говорите, что вы это делать не будете, и объясняйте причину, но не делайте ничего другого.
СБ: Я думаю, что имеется еще один вариант: «Я этого делать не буду, так что выясните, нет ли какого-то другого способа получить ответ на интересующий вас вопрос или выполнить требуемую вам функцию». Это ситуация с несколькими возможностями выбора.
БЛ: Ну конечно, так всегда и происходит. Например, функция состоит в том, чтобы зарегистрировать некоторый UserID, и выясняется, что мы пытаемся зарегистрировать UserID, который уже зарегистрирован. На уровне выше уровня регистрации требуется принять решение о том, что делать дальше. На этом уровне можно сказать: «Пардон, но в нашей системе может быть только один Брюс, и вас мы в нее никогда не впустим. Пожалуйте прочь» или «А не смените ли вы свое имя на Стив?».
СБ: А как Вы учитываете возможности отказов при разработке системы, а не одиночного приложения, когда система может быть достаточно крупной и сложной, и ей свойственны проблемы масштабируемости?
БЛ: Конечно, здесь нужно придерживаться позиции врача: не навреди в случае отказа. Другими словами, не следует предпринимать опрометчивых действий при отсутствии уверенности в их правильности. По другому это называется «быстрым выявлением сбоев» (fail fast), а я здесь имею в виду системы, в которых, большей частью, поддерживается персистентное состояние. Может оказаться очень опасным продолжать работу системы при отсутствии понимания сути сбоя. Поэтому достаточно успешной является идея быстрого выявления сбоев и склейки согласованного состояния системы на основе тщательно поддерживаемых резервных данных.
В близкой мне области систем баз данных можно много говорить о красоте моделей данных, об их мощности, о работоспособности систем, о простоте написания приложений, о возможности хранения огромных объемов данных и прочих подобных вещах, но на практике успешность этих систем определяется их надежностью. Пока системы не обрели достаточную для приобретения доверия пользователей способность надежно поддерживать данные, не допускать их потери, никто не решался доверить этим системам обработку критически важных данных.
Подход, используемый в этих системах, по существу, состоит в поддержке двух копий данных. Одна из них называется журналом восстановления, и он является подлинной копией данных. В нем содержатся записи обо всем, что происходило, в хронологическом порядке. Кроме того, имеется представление базы данных, оптимизированное для доступа и обновления «текущих данных».
Возможность систем баз данных сохранять последнее зафиксированное состояние данных, не взирая на сбои процессора, системы хранения и коммуникаций, объединенная с важными принципами транзакционности, атомарности и долговечности, придает этим системам надежность, достаточную для того, чтобы люди доверяли им поддержку критической информации. При отсутствии подобной надежности информация могла бы утратиться или исказиться.
СБ: Здесь стоило бы прояснить, какие методы используются для обнаружения ошибок.
БЛ: Обработка сбойных ситуаций всегда начинается с обнаружения сбоя – чаще всего путем использования в системе какой-либо разновидности избыточных средств, будь то биты четности или «санитарная проверка» (sanity check) в коде программы, когда 10% строк кода тратятся на проверку согласованности состояния с целью выявления того, не следует ли заняться обработкой ошибок. Таймауты, строго говоря, не являются избыточным средством, но это еще один способ выявления ошибок.
Здесь важной мыслью является то, что если вы отправляетесь в морское путешествие, имея только одни часы, то вы не можете сказать, показывают ли они правильное время. Требуется какой-то способ проверки. Например, при чтении сообщения, поступающего по сети, чтобы удостовериться в том, что ожидается именно это сообщение, можно проверить некоторые биты в заголовке сообщения и сказать: «Ага, кажется, можно продолжать работать».
Или, если вы производите чтение с диска, можно проверить метку дискового блока, чтобы удостовериться, что это именно тот блок, который запрашивался. В состоянии системы всегда имеется некоторая избыточность, позволяющая обнаружить появление ошибки.
Если не задумываться о возможности сбоев, то зачем помещать в блок диска адрес самого этого блока?
СБ: Значит, на самом деле Вы стараетесь убедиться в том, что понимаете то, что происходит в системе?
БЛ: По большому счету это именно так. И еще я стараюсь проверить то, что данные или состояние, над которыми требуется производить дальнейшую работу, являются самосогласованными.
СБ: Имеется ли какая-нибудь языковая поддержка обнаружения ошибок?
БЛ: По сути, языковая поддержка обнаружения ошибок отсутствует. В языках имеются средства обработки уже обнаруженных ошибок. Генерация исключительной ситуации средствами языка программирования – это нечто, что делается в соответствии с логикой программы.
Например, в скриптовых языках имеется очень ограниченная синтаксическая и семантическая поддержка исключительных ситуаций. И, в конечном счете, большую часть того, что предоставляется в языках, можно было бы закодировать самостоятельно.
В языках имеются некоторые довольно опасные возможности – в частности, инициирование ошибки (raise error) или исключительной ситуации, а также обработчики исключений. Как это соотносится со стеком вызовов процедур? В ранних подходах к языковой поддержке обработки ошибок стек сокращался без совершения каких-либо дополнительных действий, пока не достигался некоторый уровень, на котором было объявлено нечто, представляющее интерес для обработки данной исключительной ситуации, т.е. ошибки.
Вообще говоря, свертывание вызова процедуры или подпрограммы – вызова метода – без устранения беспорядка, который мог уже образоваться, т.е. частично произведенного этой функцией преобразования состояния, является очень опасным. Например, если имелись запросы динамической памяти, а соответствующий участок стека просто сокращается, запрошенная память так и не будет возвращена.
Поэтому очень важно дать каждому вызову процедуры возможность «аккуратно сложить свою палатку», даже если эти действия не имеют отношения к обрабатываемому исключению.
СБ: Да, похоже, что людям нужно не забывать про такие вещи, как динамическое распределение памяти. Я не знаю, имеются ли в связи с этим какие-нибудь хорошие правила? Есть ли у Вас какие-нибудь еще соображения по этому поводу?
БЛ: Ну, конечно, множество грехов в этой области покрывается сборкой мусора. Полезны также автоматические вызовы деструкторов C++ для объектов, состояние которых сохраняется в стековом фрейме. Хотя сборка мусора порождает некоторые серьезные проблемы производительности, особенно в многопотоковых приложениях, она способствует устранению ошибок, ведущих к потере памяти, а такие ошибки чрезвычайно трудно изолировать.
СБ: Кажется, что в некоторых современных языках проблема восстановления после возникновения ошибок, по крайней мере, принимается во внимание. Например, некоторые средства имеются в языке Python. По моему мнению, хорошо уже то, что люди начали думать об этой проблеме и пытаться оснащать языки соответствующими возможностями. Не знаю, насколько правильно они ее понимают.
БЛ: Хорошо, что люди начинают об этом задумываться хотя бы из-за того, что появляются новые языковые средства, побуждающие их к раздумьям о восстановлении после проявления ошибок. Но ни в каком языке нет волшебных возможностей, которые могли бы нас спасти. Все равно нужно думать о причинах того, что вызываемая процедура может не вернуть ожидаемые результаты, и о том, что можно сделать в этой ситуации.
СБ: Предположим, нам удалось обнаружить ошибку, и что следует делать далее? Можно проинформировать кого-то об этом, но встает вопрос: кого и о чем следует информировать?
БЛ: Имеются две разновидности обнаружения ошибок. В первом случае я смотрю на собственные внутренности и вижу, что они выглядят неправильно, и тогда я говорю, что возникла ошибочная ситуация. Во втором случае я вызываю некоторый другой компонент, который не делает то, что требуется. В обоих случаях я сталкиваюсь с обнаруженной ошибкой. Прежде всего, нужно «свернуть свою палатку», т.е.
восстановить состояние таким образом, чтобы управляемое тобой состояние стало согласованным. После этого нужно проинформировать ту штуку, которая тебя вызывала, возможно, выдав попутно некоторые дампы, или же можно попытаться использовать резервную логику для обхода ошибочной ситуации.
В наших проектах из области баз данных информация об ошибочной ситуации обычно передается все выше и выше по цепочке вызовов, пока на каком-то очень высоком уровне не будет сказано: «Да, дела действительно плохи. Пора производить массивный дамп памяти». При информировании об ошибке следует ее классифицировать. Следует присвоить ей имя. В каждом компоненте, информирующем об ошибках, должен иметься исчерпывающий список ошибок, информация о которых может передаваться этим компонентом.
В этом состоит одна из реальных проблем архитектуры сегодняшних языков программирования в части обработки исключительных ситуаций. В каждом компоненте должны регистрироваться все исключительные ситуации, которые могут быть возбуждены: обычно, если я вас вызываю, и вы говорите, что возбуждаете исключения A, B и C, а сами можете вызвать Джо, который возбуждает исключения D, E и F, а вы эти исключения игнорируете, то я неожиданно сталкиваюсь на своем уровне с D, E и F, хотя в вашем интерфейсе ничего не говорилось, что от вас могут исходить ошибки D, E и F. Это явление повсеместно распространено в программировании и языковых средствах. От вас никогда не требуется гарантия того, что вы объявили все ошибки, которые могут проистекать от вызова вашей подпрограммы. И поэтому разрешается игнорировать ошибки. Иногда я высказываюсь в пользу того, чтобы не разрешать игнорировать никакие ошибки. Можно изменить классификацию ошибки и передать информацию о ней на более высокий уровень, но ты не должен разрывать цепочку.
СБ: Системе точно не известно, которую информацию следует сообщать, а кому-нибудь может совсем не захотеться оказаться в ситуации, в которой придется пробираться сквозь 20 мегабайт данных, чтобы что-нибудь найти.
БЛ: В случае систем баз данных мы все более и более склоняемся к консервативному дампингу – т.е. к включению в дамп всего, что может представлять интерес. Это делается на основании того, что при наличии какого-либо используемого приложения, если при работе какого-либо производственного приложения приходится столкнуться с гейзенбагом, который трудно воспроизвести, часто бывает трудно заставить пользователей еще раз специальным образом запустить приложение, говоря примерно следующее: «Привет! Мне хотелось бы еще раз поломать вашу систему, хотя у меня имеются собственные средства для отслеживания того, что происходит».
Обычно они отвечают так: «Что? Оно же сейчас работает. Оно работает уже шесть часов. Да, эта проблема возникает раз в неделю, и нас это довольно-таки раздражает. Устраните ее, наконец. Но мы не собираемся ломать систему для вашего удовольствия».
Поэтому мы включаем в дамп все больше и больше информации. Мы не включаем в дамп саму базу данных, но если обнаруживаем подозрительную страницу, то, безусловно, направляем в дамп все ее содержимое – почти поразрядно – для возможного анализа. Слишком большой объем дампа – это не такая плохая вещь в нашей области, если приходится обслуживать эксплуатируемый код, и вам не позволительно сказать: «Привет, устройте-ка для меня еще разочек аварийный отказ вашей системы».
СБ: Когда дела идут плохо, и вы решаете выдавать дамп всего, что приходит в голову, вам могут задать вопрос: «А не лучше ли было бы узнать, что происходило в нужном месте в нужное время?» вместо того, чтобы получить дамп стека и стараться выяснить все на основе этих фотографий? Похоже, что вам нужен фильм, а не фотографии.
БЛ: Ну, конечно, если включить трассировку, то получится фильм, но опять же для этого требуется специальная возможность, и это обычно делается в центрах разработки. Часто именно с этого начинают разработчики, если ошибка является воспроизводимой, и они могут смотреть на все дампы.
Они воспроизводят ошибку при наличии подключенного к системе микроскопа и анализируют дампы трассировки – вот и получается кино.
СБ: Когда Вы разрабатываете код с учетом возможности сбоев, думаете ли Вы о ситуациях, информацию о которых следует зафиксировать, поскольку это может помочь при возможном поиске ошибки?
БЛ: Бывает так, что при раскрытии основной причины ошибки производится модификация подпрограмм построения дампа с целью включения в дамп дополнительной информации, которая помогает улучшить процесс раскрытия проблемы.
СБ: Было бы интересно поговорить о файловых системах и журналах и узнать вашу точку зрения по поводу того, насколько далеко мы ушли от прошлого, в котором имелась утилита fsck (file system check) для восстановления файловой системы после ее отказов.
БЛ: Я думаю, что в файловых системах произошла настоящая революция, когда при восстановлении после аварийного сбоя вместо сканирования диска или применения fsck стала использоваться мотивированная и инспирированная технологией баз данных система журнализации, которая журнализует изменения метаданных и затем в фоновом режиме записывает эти изменения на диск.
Здесь имеются два полезных эффекта. Один из них состоит в том, что журнал можно писать с применением высокопроизводительного устройства внешней памяти, а изменения метаданных, представленные записями в журнале, можно в отложенном режиме записывать в основную область хранения файловой системы в более позднее время, не обязательно совмещая это действие с выполнением пользовательского запроса. Кроме того, журнализация намного убыстряет восстановление файловых систем во время их перезапуска после аварийного сбоя, поскольку повторному выполнению или двойному контролю подлежат только самые последние изменения.
СБ: Давайте рассмотрим пример разработки системы, допускающей ухудшение эксплуатационных характеристик (graceful degradation). В системе Sabre, предназначенной для резервирования авиабилетов, допускается наличие дубликатов записи о бронировании (около одного дубликата на тысячу записей), поскольку оказалось, что наличие записей-дубликатов о бронировании не является слишком существенным.
Рано или поздно кто-нибудь обнаруживает наличие дубликатов и что- нибудь предпринимает. Эта система не является черно-белой. У нее имеются нечеткие границы (fuzzy edge), и в ней допускается наличие некоторых несогласованностей, потому что имеются свои способы восстановления согласованности.
БЛ: На всех уровнях системы наблюдаются деградирующие операции, начиная от систем основной памяти, в которых можно просто удалить неисправную микросхему и больше ее не использовать – следует надеяться, что это делается после восстановления состояния памяти с использованием избыточного кода с исправлением ошибок, до общесистемных явлений, когда в случае отказа системы можно перезапустить ее на резервной аппаратуре, которая, возможно, уже была частично задействована. В этих случаях имеется деградация производительности.
Вы подвергаете избыточной нагрузке одну систему, потому что другая система вышла из строя, и вы допускаете наличие пониженной производительности, пока не будет починена первая система.
Аналогично, в избыточных системах хранения на основе дисковых массивов во время восстановления вышедшего из строя диска мы наблюдаем снижение производительности при доступе к данным, которые раньше хранились на этом диске, поскольку эти данные должны воссоздаваться на основе данных, хранящихся в других блоках массива.
Так что временное ухудшение эксплуатационных характеристик наблюдается на всех уровнях системы.
Нужно вести себя очень осторожно в случае деградаций, при которых результат, возвращаемый системой, может быть каким-то образом дискредитирован. Примером может быть приложение по бронированию авиабилетов, о потере в котором записи о бронировании вы узнаете позже от клиента. Здесь требуется серьезная проверка на уровне проектирования системы, которая должна помочь ответить на вопросы: «Допустимо ли это для приложения, для внедрения этой системы?». Безусловно, мы сталкиваемся с этим в среде Web. Если полностью проигнорировать один запрос к Web-сайту из ста, ничего страшного не произойдет.
Пользователь нажмет на клавишу «refresh» своего браузера, и запрос будет обработан со второй попытки. Но если игнорировать 100% запросов в течение хотя бы нескольких минут, то известие об этом попадет в New York Times.
Так что мы видим, что решение о том, как реагировать на ошибки – не выдавать ли ответ вообще или выдавать частичный ответ, в действительности зависит от того, для чего будет использоваться этот ответ, и какова будет реакция клиента на неправильный ответ или отсутствие ответа.
СБ: Что Вы можете сказать относительно связи между отладкой системы и обнаружением ошибок и восстановлением системы после их проявления?
БЛ: Имеется две обширных категории сообщений об ошибках. Сообщения первой категории означают, что система предвидела данную проблему, например, попытку регистрации пользователя с уже использующимся в системе именем или выход значения параметра за пределы допустимого диапазона, а теперь сообщает вам, что эта проблема действительно возникла. Большинство систем с этим справляется плохо. Получаемые пользователями сообщения об ошибках в лучшем случае являются непонятными, а в худшем – вводящими в заблуждение. Это является результатом ряда проблем. Одна из них заключается в том, что во многих средах разработки программного обеспечения имеется отдельная небольшая подсистема, предназначенная для поддержки сообщений об ошибках. Для создания нового сообщения об ошибке нужно потратить полчаса на ввод сообщения об ошибке, нужно убедиться в том, что это сообщение является пригодным для перевода на национальные языки, и нужно присвоить ему код ошибки, отличный от тех, которые уже были выделены для других сообщений об ошибках. Чтобы избежать этой работы, многие люди повторно используют старые сообщения об ошибках, говоря, что данная ошибка похожа на ту, которая уже зарегистрирована в системе, и что можно использовать существующее сообщение.
Программистская лень приводит к отсутствию конкретности в сообщениях об ошибках.
Если можно сделать выбор между непараметризуемым сообщением, в котором просто констатируется факт ошибки, и намного более сложным параметризуемым сообщением, для которого нужно написать 15 строк кода, то программисты однозначно выбирают первый вариант.
Я думаю, что компании, занимающиеся разработкой программного обеспечения, недостаточно стимулируют правильную и точную формулировку сообщений об ошибках (и в компаниях, производящих аппаратуру, дела обстоят не намного лучше).
СБ: Когда вы производите сообщение об ошибке, вы должны знать, для кого оно предназначено, и что эти люди знают о происходящем в системе. Насколько принято испытывать сообщения об ошибках с привлечением сообщества пользователей? Мне кажется, что очень конструктивной была бы обратная связь.
БЛ: Зачастую текст сообщения об ошибке формулируется разработчиком, погруженным во внутренности системы, такой текст, очевидно, не отвечает потребностям конечных пользователей. Как я уже говорил, такие тексты являются недостаточно конкретными.
Но пока разговор шел про первую категорию сообщений об ошибках, т.е. тех, для которых достаточно понятна связь между данными, вводимыми пользователем, и соответствующей ошибкой. Сообщения об ошибках второй категории выдаются в тех случаях, когда система понимает, что она повреждена. В таких случаях сообщения в действительности совсем не рассчитаны на конечных пользователей и часто вообще ничего не говорят им. Подобные сообщения выглядят примерно так: «Оператор не может быть выполнен. Попробуйте выполнить другой оператор».
По существу, это сообщение является признанием системы, что в ней имеется ошибка, и в данный момент для исправления этой ошибки – неважно, программный это сбой или аппаратный – требуется гораздо больше информации. Выдача полного дампа бесполезна для бедного конечного пользователя.
Поэтому в большинстве серьезных систем – аппаратных и программных – поддерживаются наборы данных журнализации ошибок, и при возникновении ошибок подобного рода система сбрасывает в эти наборы данных дамп, содержащий массу информации о деталях состояния системы, которые могли привести к ошибке, и о действиях системы во время проявления ошибки.
СБ: Что такое гейзенбаги?
БЛ: Этот термин родился в моем присутствии. Гейзенбагами называются ошибки (баги), которые явным образом демонстрируют некорректное поведение системы, но такие, что при попытке разобраться в причинах этой некорректности проблема исчезает. Обычно для того чтобы можно было разобраться в причинах некорректности, включается трассировка, или добавляются дополнительные параметры, или что-то изменяется. И из-за этих изменений проблема исчезает. Довольно часто подобные проблемы проявляются в связи с параллельной работой программ. Или же они могут проявляться в зависимости от конкретного способа размещения программ и данных в основной памяти.
Так что настоящее определение гейзенбага состоит в следующем: когда вы смотрите на эту ошибку, она исчезает – с уважением к доктору [Вернеру] Гейзенбергу, который говорил: «Чем более пристально вы смотрите на что-то одно, тем менее отчетливо можете увидеть что-либо иное».
СБ: Я думаю, что хорошо, когда случается нечто, представляющее известную реальную неполадку, поскольку обычно это означает, что неисправность возникла на более низком уровне системы – при распределении памяти или выполнении каких-то других подобных действий.
БЛ: Такие ошибки очень трудно находить, но, конечно, чем труднее ошибка, тем больше удовольствия доставляет ее обнаружение.
СБ: Как происходит обнаружение ошибок и восстановление после их проявления в распределенных системах, которые по своей природе обладают высоким уровнем параллелизма и включают массу слабо связанных компонентов?
БЛ: Распределенные системы разбиваются на две обширные категории. В первой категории одна система использует другую систему для выполнения некоторых функций. Здесь первая система зависит от возможности второй системы выполнять эти функции. Примером такого зависимого использования являются Web-сервисы. Во второй категории распределенные машины совместно обеспечивают некоторый единый сервис. Примером могут служить распределенные файловые системы.
Наибольшее внимание уделяется возможности восстановления после сбоев и надежности систем второй категории, поскольку идея таких распределенных систем часто состоит в том, что функциональные возможности системы может обеспечить любой сервер – нужно всего лишь найти тот из них, который исправен и функционирует, а также участвует в данной игре. Но поскольку эти серверы поддерживают распределенное состояние, имеется громадная проблема выяснения того, кто участвует в игре. Имеются алгоритмы группового консенсуса. Имеется важная теорема, в которой говорится, что при наличии нормальных условий передачи сообщения – или при наличии предельных условий передачи сообщений – в локальной системе невозможно определить, произошел ли сбой другой локальной системы, или она просто медленно работает, или же имеет место сбой исходной локальной системы, т.е. она лишена возможности коммуникации.
Эти алгоритмы можно практически реализовать. Имеется много хороших алгоритмов. Выполнение таких алгоритмов обходится не очень дешево, но их можно использовать для поддержки списка работающих серверов и информирования каждого сервера обо всех других работающих серверах, поскольку, вообще говоря, в поддержке распределенного состояния должны участвовать все работающие серверы.
СБ: Одним из интересных аспектов здесь является соотношение между временем, требуемым на обнаружение чего-либо, и временем, которое приходится затрачивать на реальное восстановление системы.
БЛ: А также, что значит удалить отказавший компонент, поскольку здесь имеется проблема расщепления разума (split brain problem), когда я думаю, что отсутствуете вы, а вы считаете, что отсутствую я? Кто несет ответственность?
СБ: Ну да, и пока они спорят об этом, ничего не происходит.
БЛ: Такое возможно, хотя некоторые из этих систем могут продолжать обслуживание. Редко бывает так, что для выполнения одиночного действия в распределенной системе требовалось участие всех активных партнеров.
Имеется также проблема вывода из игры неисправных партнеров.
Если нас всего пятеро, и четверо считают, что пятый мертв, то для гарантии того, что он мертв, стоит выпустить в него еще три пули.
Мы встречаемся с этим, в частности, в области совместного управления дисками, где имеются два процессора, две системы, подсоединенные к одной и той же дисковой подсистеме. Проблема состоит в том, что если одна система принимает на себя управление дисковой памятью вместо другой системы, то первой системе лучше вообще не пользоваться дисковой подсистемой. Мы пытаемся найти архитектурные средства в дисковых подсистемах для вытеснения участников – так называемые ограждающие средства.
Если я думаю, что вы мертвы, и хочу взять на себя управление внешней памятью и ответственность за это, то, прежде всего, мне захочется сказать дисковой подсистеме, чтобы она не обращала на вас внимания, поскольку теперь за все отвечаю я. Если у вас возникнет возможность продолжать использовать дисковую подсистему, в то время как я блаженно верую, что единолично за нее отвечаю, то могут произойти ужасные вещи.
Имеются два аспекта совместной работы в распределенных системах. Один из них состоит в выявлении участников игры, а другой – в том, что если кто-то считается выбывшим из игры, то необходимо каким-то образом абсолютно убедиться, что он действительно больше не играет.
СБ: Обнаружение ошибок и восстановление затруднительны в многопотоковых приложениях. Значит ли это, что не следует создавать многопотоковые системы?
БЛ: Я думаю, что нам нужно разрабатывать многопотоковые системы, но это трудное дело. Я обычно говорил людям: «Если вы не занимались созданием многопроцессного кода в течение пяти лет, то у вас нет квалификации, достаточной для написания такого кода». А потом я понял, что, пока я придерживаюсь такой позиции, никто не собирается меня заменять. Поэтому я стараюсь помогать людям в понимании того, как следует писать многопроцессный код. Имеется куча методов, но в основном необходима синхронизация критических участков и масса проверок.
Преимущества мультипроцессного кода и использования разделяемой памяти настолько неотразимы, что нам приходится делать это.
СБ: Мне кажется, что состояние дел в области обнаружения ошибок и восстановления не слишком изменилось за последние 20 лет.
БЛ: Одной из вещей, которые мы теперь понимаем немного лучше, является так называемая область действия ошибки (scope of the error). Испортила ли ошибка только одну функцию? Вы вызываете эту функцию, а она не работает. Она говорит: «Я сломалась, возврат». В этот момент областью действия ошибки является эта функция. Конечно, если вы делаете возврат, если вы возбуждаете исключительную ситуацию, то область действия ошибки расширяется. Вы должны решить, ограничена ли область действия ошибки данным потоком управления. Если ошибка проявляется вне каких-либо манипуляций с разделяемыми данными, вы можете сказать: «Может быть, если мы всего лишь ликвидируем этот поток управления, то остальные потоки смогут продолжать работать, а может быть, мы даже сможем перезапустить этот поток управления, и в следующий раз его судьба окажется более удачной».
СБ: А как это представляется в коде?
БЛ: Обычно посредством механизмов управления потоками, которые требуются при написании любого многопотокового приложения. Поток может закончиться, и тогда менеджер потоков скажет: «О, этот поток относился к такому виду потоков, которые нужно перезапускать, если они заканчиваются».
Например, в системе баз данных вы можете подать в систему некоторый оператор, а система может разволноваться и сказать: «Ой, я не могу разобраться с синтаксисом этого оператора». Это ошибка пользователя, и мы были бы счастливы сообщить ему это, но потоку, который мог бы это сделать, нужно принимать на обработку другой оператор или даже повторно тот же самый оператор.
Если посмотреть на другой край спектра, то может выйти из строя диск журнала, и мы не сможем писать в журнал записи. В этот момент лучше приостановить все шоу.Должна иметься возможность перезапустить программное обеспечение и начать обеспечивать сервис на резервной аппаратуре. Нам требуется справляться с аварийными ситуациями масштаба вычислительной системы. Обо всем этом нужно задумываться с самого начала разработки приложений и подсистем.
Прокомментировать>>
Метатехнология и технология самоорганизации
В реальном проекте технология самоорганизации создается самой командой, возможно, с помощью профессионалов по данному вопросу. Сам процесс ее разработки является мощным интегрирующим фактором в деятельности КМП.
Она разрабатывается на стадии ЖЦ команды «Нормализация деятельности (normalizing)» и корректируется в последующем исходя из реальных условий. Поэтому говорить о единой «технологии самоорганизации» для всех типов и видов проекта некорректно. Однако, возможно говорить об уровне метатехнологии для достаточно большого числа проектов, характеризующихся сходными параметрами.
На базе такой метатехнологии самоорганизации команды, например, для IT-проектов, создается своя «технология самоорганизации команды конкретного проекта», учитывающая ресурсные возможности, особенности проекта, организационную культуру компании, уровень профессионализма членов команды, стандарты (международные, национальные, корпоративные) по менеджменту и управлению проектами и многое другое.
Метатехнологию можно сформулировать для достаточно широкого спектра проектов. Она является базой (организационной моделью и моделью деятельности) для создания адекватной конкретному проекту и конкретному набору членов команды ТСО.
Иначе, готовых рецептов нет. Большинство попыток свести управление современным проектом к работе по операциям и к управлению в технических системах не увенчались успехом.
Таким образом, метатехнология является базой и совокупностью инструментов для построения ТСО команды под конкретный проект.
Область применимости
На начальной стадии проекта (start-up) используется практика проведения стартовых семинаров, тренингов или интеграционных процедур для создания и организации работы команды (Team Building). На этой стадии понятие «самоорганизации» не применимо и не имеет смысла. На стадии расформирования и/или реорганизации команды сам термин «самоорганизация» выглядит странно. Поэтому «технология самоорганизации» применима только к процессу развития команды (Team Development).
Начинается ее разработка на стадии «Нормализация деятельности (normalizing)» жизненного цикла КМП. На этой стадии члены команды приходят к взаимному согласию в результате переговоров и принятия компромиссов и разрабатывают нормы и правила, на основании которых будет построена их дальнейшая работа.
Сама технология «работает» на стадии «Исполнение планов по выполнению проекта (performing)», т.е. уже после того, как мотивация членов команды определена и ориентирована на успешное выполнение проекта, процесс осуществления проекта стабилизируется, эффективность работы команды возрастает, каждый член команды знает свою роль и т.п.
Следует также учесть, что при фазовых переходах в проекте (переход от одной фазы или стадии ЖЦП к другой) всегда необходимо проводить корректировку деятельности КМП с учетом изменившейся проектной ситуации. Как следствие, требуется также провести и ревизию некоторых элементов используемой технологии самоорганизации. Недооценка потребностей в изменениях может привести к неадекватности используемой технологии самоорганизации и изменившейся КМП.
Условия применимости
Самоорганизация возможна при определенных условиях:
сведение «искусства управления» к выполнению операций;
ограничения на самостоятельность действий члена КМП на уровне постановки задачи; иначе: «что делать?» - задается в рамках интегрированного контекста проекта и целей проекта;
свободный выбор инструментов для решения вопроса «как делать?» в рамках ограничений на ресурсы, временные параметры и требования к результатам проекта
согласование и координация промежуточных результатов - по проекту, его фазы (стадии), по задаче.
Иными словами, в рамках ТСО КМП:
уровень и границы осуществления стратегии проекта задаются и координируются в рамках командных действий;
осуществление тактических действий предполагает принятие самостоятельных решений и свободный выбор инструментов в рамках ограничений на решаемую задачу.
Процесс. Статичность процесса определяется управленческой культурой команды, включающей систему ценностей, ментальность и образ командных действий для данной совокупности индивидуумов, образующих команду, и целями (задачами) проекта.
Изменяющийся интегрированный контекст проекта и ход проекта определяет динамику изменений самой команды. Сам процесс самоорганизации является динамическим. На его входе – КМП, которая должна быть уже построена, т.е. проведен процесс Team Building, интегрированный контекст проекта и метатехнология ТСО. На выходе – успешное завершение проекта и изменившаяся КМП.
Технология. Определяется самим проектом, совокупностью индивидуумов – членов Команды, совокупностью управленческих ролей КМП и их весом для конкретного проекта и/или его жизненной фазы, профессиональным и человеческим совокупным потенциалом членов команды и, в ряде случаев, других участников проекта. Следует учесть, что совокупный профессиональный и личностный потенциал членов КМП должен превышать требующийся для осуществления ТСО (требование избыточности системы).
Вид проектной команды. Представление о самоорганизации применимо к управленческому звену проекта (команде или группе менеджмента проекта) или когда вся команда проекта не превышает 10-12 чел.
Требования к членам команды. Для каждого члена КМП, сознательно участвующим в процессах самоорганизации командной и личной деятельности по проекту, необходимыми начальными условиями являются:
адекватность культуре команды менеджмента конкретного проекта;
понимание каждым своей роли, как элемента целого под названием «команда проекта»;
знание и принятие выработанных в результате согласования между членами КМП норм, правил и процедур совместной работы в рамках конкретного проекта.
Для каждого члена КМП в самом процессе исполнения проекта при использовании технологии самоорганизации необходимыми условиями являются:
соблюдение выработанных норм и правил (формально оформленных и неформальных);
следование принятым процедурам;
постоянный мониторинг прогресса проекта с целью корректировки норм, правил и процедур.
Адаптация
Функционирование любой самоорганизующейся системы обусловлено ее отношениями с внешней средой и реакциями приспособления к изменениям в ней. Адаптивная система должна выполнять свои функции, наиболее эффективным путем в зависимости от состояния окружающей среды. Уникальным свойством самоорганизующейся системы является изменение (корректировка) ее структуры и функций, адекватных изменениям внешней среды и наличие памяти.
Адаптация КМП происходит за счет изменения взаимосвязей между ее элементами и корректировки ее управленческих функций с целью выполнения проекта наиболее экономичным путем.
Аннотация
Для того чтобы Команда Менеджмента Проекта (Project Management Team) была готова к совместной работе и, в последующем, к эффективной самоорганизации, требуется, чтобы каждый ее участник был интегрирован в команду и в проект.
Сами процессы самоорганизации команды должны быть обеспечены мониторингом и механизмом управления изменениями, которые включают систему норм, правил и процедур, определяющих поведение и действия ключевых участников проекта и активную обратную связь.
В настоящем докладе рассматривается технология самоорганизации КМП на стадии исполнения проекта или его фазы с точки зрения самоорганизации систем.
Целесообразность.
Под целесообразностью понимается общая характеристика поведения сложных динамических систем (в случае КМП – организационной и социальной), описывающая ориентацию системы на достижение целей и получение определенных результатов.
Целью самоорганизующейся системы является модель «желаемого будущего», а в рамках КМП – достижение запланированных целей и получение ожидаемых результатов проекта, как результатов сознательной деятельности всей команды.
С точки зрения определения целей ТСО команды сложностью является большое количество персональных характеристик членов Команды, которые имеют разные оценочные шкалы, не имеют однозначных трактовок и проявление которых зависит от конкретной ситуации по проекту. Также немаловажную роль играют динамика изменений окружающей среды проекта, неопределенность и неоднозначность информации о внешней и внутренней среде проекта, «человеческий» фактор и т.п.
Иерархическое строение.
В КМП иерархия уровней управления отсутствует, поэтому деятельность выстраивается на связях координации и партнерства. В этом сущность менеджерской команды и ее принципиальное отличие от таких типов проектных команд, как команда управления проекта и команда проекта. Поэтому в рамках КМП используется иерархия целей и задач проекта и ответственности членов КМП. Каждый зависит от каждого и эффективная работа всей команды является совокупностью вкладов каждого ее члена. Если сравнить КМП с тепловозом, то неисправность или отсутствие тех или иных узлов не позволяет ему выполнять работу, для которой он предназначен. В данном случае вопрос о том, какой узел важнее, не возникает.
Инструменты менеджмента проектов для ТСО КМП
Возникающие трудности при выборе инструментов всегда связаны с уникальностью проекта (по определению). Уникальность проекта всегда требует создания уникальной команды проекта, т.к. вне проекта «команда проекта» не существует. Поэтому совокупность инструментов можно в той или иной степени определить, однако их набор и взаимосвязи в обязательном порядке формируются под конкретный проект в рамках групповой работы конкретных членов КП.
Для того, чтобы поддержать необходимую эффективность деятельности команды, как системы, и избежать возможной подмены целей проекта и команды на групповые или индивидуальные цели, используется ряд инструментов для организации деятельности команды. В частности:
партисипативный менеджмент проекта;
согласованные взаимные ожидания и требования, как членов команды, так и других участников проекта;
определенные границы самостоятельности каждого члена команды в рамках собственной ответственности в принятии решении о сроках, распределении и использовании ресурсов, результатах по проекту;
групповая позитивная синергия;
адекватная и справедливая система мотивации членов КМП;
сбалансированная обратная связь;
и другие.
В качестве регулирующих процесс самоорганизации инструментов можно использовать:
корпоративные стандарты, правила и нормы;
процедуры;
развивающие мероприятия по корректировке адекватности профессионализма управляющего проекта и членов команды целям и задачам проекта;
систему регулярных событий, формирующих единый информационный контекст проекта – рабочие совещания по проекту, отчеты по прогрессу и т.п.;
другие, определяющиеся конкретным проектом.
Интерпретация системных свойств применительно к КМП.
Применительно к КМП свойств системы можно интерпретировать следующим образом:
Литература
Cleland David I. Strategic Management of Teams. John Wiley & Sons, Inc., New York, 1996. – pp. 292.
Cleland D.I., Project Management: Strategic Design and Implementation. - New York, NY: McGraw Hill Publishing Company Inc., 1999. – pp.560.
Михеев В.Н. Проектный Менеджмент для проектно-ориентированных компаний. «Консалтинг», № 1-2, 2002, с. 16-27.
Verma V., Managing the Project Team. The Human Aspects of Project Management. – V.3, Pennsylvania, PA: PMI, 1997. - pp.296.
Михеев В.Н. Современная команда менеджмента проекта. ComputerWorld. Директору информационной службы, май 2001г., сс. 14-21.
ICB - IPMA Competence Baseline. Version 2.0. IPMA Editorial Committee: Caupin G., Knopfel H., Morris P., Motzel E., Pannenbacker O.. - Bremen: Eigenverlag, 1999. - pp.112.
Михеев В.Н., Товб А.С. Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.33-37.
С.Н. Брайнес, Свечинский В.Б. «Принципы организации сложных биологических систем управления»,Москва, Наука, 1967г.
Н.А.Бернштейн». Пути развития физиологии и связанные с ними задачи кибернетики. Биологические аспекты кибернетики»,Москва,Наука, 1969г.
В.П.Кузнецов, М.А.Раков. «Самоорганизация в технических системах», Киев, НАУКОВА ДУМКА, 1987г.
Завадский К.М.»К проблеме прогресса живых и технических сисием», Ленинград,Наука,1970г.
У.Р.Эшби «Принципы самоорганизации», Москва,Мир,1966г.
Память
Память, как способность к воспроизведению прошлого опыта в рамках деятельности Команды, позволяет работать быстрее и эффективнее. Накопление информации в процессе осуществления проекта, т.е. формирование опыта, позволяет предсказывать ход проекта системы в его непрерывно изменяющемся контексте. Как следствие, в ряде случаев решения на основе предсказания хода проекта, базирующегося на основе прошлого опыта, оказываются эффективнее, нежели решения, принятые без его учета.
Однако такой путь далеко не всегда является наиболее эффективным. В ряде случаев, использование памяти, как совокупности стереотипов подходов и деятельности, приводит к принятию типовых, простых и неверных решений в нетипичных случаях.
Разнообразие состояний
Разнообразие состояний КМП обуславливается многочисленностью ее элементов, имеющих разную природу (человеческую, социальную, техническую и проч.) и наличием различных как измеряемых, так и неизмеряемых явных и неявных связей между ними.
Для того, чтобы использовать ТСО надо создать КМП, обладающую или способной создать в себе еще большее разнообразие, чем разнообразие решаемых проектных задач. Иначе, совокупный потенциал (профессиональный, человеческий, трудовой) КМП должен быть большим, нежели необходимый для осуществления данного проекта. В условиях недостаточного совокупного потенциала КМП или отсутствия ее целостности ТСО просто не будет работать.
Целостность КМП, как системы, проявляется в возникновении новых интегративных качеств, не свойственных образующим ее компонентам, т.е. свойства КМП не являются суммой свойств ее элементов. Такое проявление целостности называется синергией КМП.
При использовании системного подхода для
При использовании системного подхода для построения ТСО КМП всегда следует учитывать неопределенности в проекте, которые связаны с влиянием человеческого фактора. Поэтому типовые подходы можно определить на уровне метатехнологии для групп проектов, обладающих сходными характеристиками.
Для конкретного проекта всегда требуется построение уникальной ТСО на базе метатехнологии самоорганизации для определенного типа проектов с учетом особенностей конкретного проекта, «зрелости» компании-исполнителя, профессионального потенциала и особенностей индивидуумов, входящих в КМП.
Целесообразность использования ТСО определяется в каждом конкретном случае и зависит от масштаба проекта (чем выше объемы, тем большая эффективность), его длительностью (чем продолжительней проект, тем большая экономия высокопрофессионального управленческого ресурса) и профессионализма индивидуумов (чем выше профессионализм и мастерство, тем больший эффект).
Использование ТСО возможно только при определенных условиях: на стадии Team Development, при наличии достаточного для получения кумулятивного эффекта профессионального и человеческого потенциала членов КМП, установленных и выполняемых правилах и процедурах совместной и индивидуальной работы членов КМП.
Использование ТСО возможно в такой КМП, совокупный потенциал членов который превышает необходимый совокупный профессиональный потенциал, требуемый для осуществления конкретного проекта (требование избыточности системы).
Системные характеристики КМП.
КМП можно рассматривать как систему, обладающую определенными характеристиками. В этом случае, в качестве подхода к построению ТСО команды можно использовать основные положения теории самоорганизующихся систем [8-12].
Под самоорганизующимися системами понимаются открытые системы, в которых происходит (или произошел) спонтанный процесс упорядочивания, обусловленный свойствами элементов самой системы В этом случае под самоорганизацией понимается целенаправленный процесс, в ходе которого создается, воспроизводится или совершенствуется организация сложной динамической системы [9].
Применительно к КМП, под ее самоорганизацией понимается целенаправленный динамический процесс самостоятельного принятия решений и осуществления действий, позволяющий сделать оптимальный выбор из множества вариантов решений и действий и провести соответствующую корректировку хода проекта.
В этом случае целесообразно идентифицировать КМП как систему, определить необходимые и достаточные условия ее самоорганизации, а также определить область применимости ТСО КМП в проектной деятельности.
В КМП, как в системе, можно выделить:
Элементы. Каждый элемент может выполнять функцию (функции) и/или обладать алгоритмом действия. Иначе, каждому члену команды необходимо иметь свою роль, область деятельности и ответственности и в КМП, и в проекте.
Связи. За сохранение структуры и целостности системы отвечают связи между элементами. В рамках КМП под связями понимается совокупность формальных и неформальных отношений между членами команды, которые определяются как измеримыми, так и не измеримыми характеристиками (например, культура, чувства, взгляды, убеждения и т.п.).
В самоорганизующейся команде обратные связи должны компенсировать любые возмущения, возникающие в проекте (отрицательные обратные связи), а также быть стимулом для улучшения исполнения проекта со стороны членов КМП (положительные обратные связи).
Свойства. КМП, как система, должна обладать следующими свойствами:.
Целесообразностью.
Иерархическим строением.
Адаптацией.
Памятью.
Разнообразием состояний.
Влияние внешних факторов, например, динамики
Влияние внешних факторов, например, динамики развития рынка и появление новых рынков, изменения управленческих парадигм, повышения комплексности самих проектов, развитие менеджмента проектов, как стратегической управленческой культуры и профессиональной области деятельности и проч. требуют разработки новых подходов к деятельности по проектам, отличающихся технологичностью, рациональностью и эффективностью. В свою очередь, изменение макро- и микросреды проектной деятельности принципиально изменяет внутреннюю среду проекта и требует использования адекватных известных и создание новых инструментов1 в менеджменте проектов.
Потребность в технологизации некоторых компонентов проектной деятельности, ранее являющихся предметом «искусства», «мастерства», «ноу-хау (know-how)» и интуиции «зрелых» профессионалов. определяется расширением применения менеджмента проектов и, как следствием, недостатком в высокопрофессиональных менеджерах проектов.
Сведение к «технологии» тех компонентов профессиональной деятельности «зрелого» менеджера проектов, которые всегда являлись характеристикой его класса и «ноу-хау» работы, требует большой осторожности, хорошего опыта и взвешенного подхода. Однако, переосмысление и развитие современного менеджмента проектов, как управленческой интегративной культуры, стратегии деятельности в рыночных условиях и командной «игры», позволяют решать задачи, ранее не стоявшие на повестке дня.
Одной из таких актуальных задач является самоорганизация проектных команд для эффективного выполнения проекта. Актуальность задачи и готовность к ее решению определяется:
стратегическим характером современного менеджмента проектов и соответствующего подхода к деятельности компаний в рыночных условиях [1-3];
многообразием типов проектных команд (самоуправляемые, самомотивирующиеся и т.п.), их культурой и современным подходом к созданию и деятельности команд проектов [4];
сущностью современной команды менеджмента проектов и ее многопозиционностью в проекте (как субъекта управления, как элемента технологии осуществления проекта и как группы индивидуумов) [5];
общим трендом к стандартизации проектной деятельности и унификации требований к профессионализму и мастерству менеджеров проектов [6,7].
В общем случае, под « технологией самоорганизации Команды менеджмента проекта (КМП)» понимается взаимосвязанная совокупность норм и правил, инструментов и действий, используемых с целью обеспечения процессов саморегулирования, самообучения и самоорганизации КМП, как элемента метатехнологии осуществления проекта.
Если использовать системный подход к формированию и использованию такой «технологии самоорганизации» (ТСО), то целесообразно:
рассмотреть КМП, как систему;
определить область и условия применимости ТСО КМП;
сформулировать метатехнологию самоорганизации КМП с точки зрения самоорганизующихся систем;
определить возможные наборы инструментов Project Management для разработки и реализации ТСО КМП.
Данный подход также применим, в частности, для проектов, в которых вся команда проекта не превышает 10-12 человек и формирование отдельной КМП нецелесообразно. Однако, в этом случае, сама ТСО должна включать не только управленческие компоненты, но и учитывать особенности профессиональной деятельности по проекту других членов команды.
Запуск процесса самоорганизации
Сама по себе самоорганизация не происходит. Естественным образом происходит только повышение энтропии, развитие беспорядка, хаоса и развал работы. Поэтому процесс надо «запустить» и сознательно «силовым» способом поддерживать систему регуляторов этого процесса (регулировать границы процесса самоорганизации КМП).
Для запуска нужно иметь:
Сформированную КМП, прошедшую этап start-up и Team Building.
Заданные форматы и формы повторяемых (цикличных) действий.
Заданные правила: их наличие, принятие членами КМП и соблюдение.
Действия: обязательные периодические и регулярные.
Коммуникации: формальные, неформальные, личностные.
Информация: интегрированный информационный контекст проекта.
Изменения методологии в режиме реального времени
И, наконец, последний из наиболее важных факторов при создании методологии - подгонка нужной методологии непосредственно в ходе работ. Коль скоро мы понимаем, что каждый проект заслуживает своей собственной методологии, то становится очевидно, что изначальные предположения о том, какую методологию следует использовать, это всего лишь наша первая попытка угадать, что же нам в действительности понадобится. Вот тут-то и становится заметна роль инкрементных разработок.
Если мы будем проводить опрос среди разработчиков в середине итераций и между ними, то мы получим возможность учитывать самые свежий опыт работы. Если же мы будем учитывать этот опыт, то команда получит возможность улучшать используемую методологию прямо по ходу работ.
Впрочем, описание динамического изменения методологии не входит в рамки этой конкретной статьи. Некоторую информацию по этой теме можно почерпнуть в работе [Cockburn98], но более подробно она будет представлена в отдельной статье.
Каждому проекту своя методология
В предыдущих разделах статьи мы уже показали, что существует множество различных методологий (и это совершенно естественно) - см. рис. 5. Все они отличаются друг от друга с точки зрения количества занятых в проекте людей, критичности проекта, приоритетов и, возможно, философии разработчиков.
Рисунок 5. Методологии, организованные по принципу люди х критичность х приоритетность.
На рисунке 5 вы видите семь возможных размеров проекта и четыре зоны его критичности. Такое деление достаточно условно, хотя и правдоподобно - мой опыт подсказывает, что именно такие показатели свидетельствуют о необходимости изменения характера методологии, применяемой в проекте. Каждой ячейке схемы может одновременно соответствовать сразу несколько различных методологий. Выбор будет зависеть от предпочтений спонсоров проекта - ставят ли они на первое место производительность, обозреваемость, повторяемость или корректность процесса. "Размер" методологии растет по мере приближения к правой стороне схемы (больше людей, больше коммуникационных элементов в методологии), а "плотность" - к верхней ее части (более строгий контроль). Согласно Принципу 3, чем правее или выше, тем больше стоимость разработки проекта, поэтому те, кто озабочен экономической стороной вопроса, должны постараться разместить свой проект как можно левее и ниже. Бывают ситуации, когда прочие стимулы, например, престиж руководителя проекта или безопасность собственной карьеры, могут заставить вас считать проект "более значительным и критичным", даже если это приведет к увеличению стоимости разработок.
Самое замечательное, что эта схема действительно приблизительно соответствует реальному положению дел. Мы можем сосчитать количество занятых в проекте людей, обсудить его критичность и приоритеты. Используя описанные выше принципы, мы можем принять некие базовые решения относительно того, какую методологию следует использовать в данном конкретном проекте. В конце концов, все остальное решают личные предпочтения. Ниже я приведу несколько примеров из личного опыта и расскажу, как мне самому удавалось применять эти идеи и принципы на практике.
Компоненты и объем методологии
Под "методологией" я понимаю то, что написано в качестве первого толкования этого слова в Американском словаре Miriam-Webster: "ряд связанных между собой методов или техник". Оксфордский словарь толкует это слово только как "изучение методов". В этой статье я использую американский вариант. (Для интересующихся: в "Толковом словаре русского языка" Ожегова это слово трактуется как "принципы и способы организации теоретической и практической деятельности" и "совокупность методов, применяемых в какой-либо науке". -- прим. переводчиков)
Под "размером" методологии я имею в виду число элементов управления в ней, к которым относятся поставляемые артефакты, стандарты, виды деятельности, меры качества и т.д. "Плотность" методологии измеряется уровнем детализации и связности, необходимых для ее осуществления. Более высокая плотность соответствует жесткому контролю или сильному формализму. "Вес" методологии определяется путем умножения размера на плотность (только теоретически, так как я не привожу здесь никаких цифр относительно размера и плотности).
Я буду говорить также о "размере проекта". Под этим термином я подразумеваю число людей, работающих над проектом, деятельность которых необходимо координировать. Нередко возникает мнение, что размер проекта соответствует размерам задачи, но все не так просто. Размер задачи нельзя определить в абсолютных величинах, так как всегда может появиться новый человек, который сумеет разглядеть в этой задаче некоторый упрощающий паттерн. Именно поэтому я старательно разграничиваю понятия "размер проекта" и "размер задачи".
Рисунок 1. Составляющие методологии (с примерами).
Методология включает в себя, по крайней мере, те предметы и темы, которые указаны на рис. 1: роли, навыки, команды разработчиков, инструментарий, техники, виды деятельности, стандарты, рабочие продукты, меры качества и систему ценностей, принятых в команде разработчиков.
В большинстве своем, эти пункты не нуждаются в дополнительных объяснениях. Под "стандартами" мы имеем в виду нотационные стандарты (например, диаграммы и языки программирования), которые используются при выполнении данного проекта. Есть также стандарты управления и принятия решений, например, использование инкрементных разработок. И, наконец, у нас есть некоторая система условностей - стандартов, которые определяются для данного конкретного проекта.
Менее очевидно, что такое "система ценностей, принятых в команде разработчиков". Под этим термином мы понимаем то, к чему стремится команда, как они предпочитают общаться и работать. Для команд с различными системами ценностей будут эффективны различные методологии.
У методологии есть "объем", который определяется протяженностью жизненного цикла проекта, разнообразием ролей и видов их деятельности, которые и пытается покрыть собой методология (см. рис. 2):
Рисунок 2. "Объем" методологии.
Некоторые компании работают по методологиям, которые покрывают весь процесс разработки программного продукта - от первого звонка клиента до поддержки и сопровождения уже работающей системы. При этом все роли оплачиваются из фондов проекта. Большая часть тех коммерческих книг, которые именуются "методологиями", посвящены, как правило, описанию только одной роли, а именно, роли проектировщика/программиста. В таких книгах рассказывается о том, как нужно проектировать, уделяется большое внимание нескольким различным техникам и стандартам изображения диаграмм. Если мы сравним тот объем задач, который должна охватывать методология, с той информацией, которая содержится в этих книгах, сразу станет понятно, почему у загруженных работой программистов такие "методологии" вызывают лишь досаду и раздражение. На самом деле, то, какие техники или стандарты изображения диаграмм использует проектировщик, создавая дизайн системы, не оказывает существенного влияния на конечный успех проекта, который конечно же, является наиболее важным фактором в любом бизнесе.
Краткий обзор
"Методология с большой буквы" - это название того, как организация многократно производит и поставляет программные системы:
кого в ней нанимают на работу и зачем, чего ожидают люди от своих коллег, какие условности они соблюдают, начиная от размещения рабочих мест в офисе и до используемых рабочих продуктов. Когда какая-то компания помещает в газете объявление о приеме на работу, это объявление представляет собой некий артефакт принятой в этой компании методологии. Как оказалось, чтобы получить практические результаты от изучения методологии, мы должны рассматривать ее именно с такой широкой точки зрения.
В данном случае, моей целью было создать откровенный диалог между людьми, придерживающимися различных взглядов на этот вопрос, и обозначить принципы, согласно которым можно рекомендовать ту или иную методологию. Итак, сначала нам надлежит ответить на следующие вопросы: Что же такое "методология"? Должно ли методологий быть много? Может ли одна быть "лучше", чем другая? Как узнать, какие элементы методологии стоит перенимать? Как применить все эти знания в крупном проекте?
Существование множества методологий совершенно необходимо. Их можно классифицировать по размеру команды разработчиков и критичности системы
(разумеется, их можно классифицировать по гораздо большему количеству величин, однако эти две лучше всего подходят для изначальной оценки). Затем те, кто занимаются проектированием методологии, определяют рассматриваемые вопросы, роли, виды деятельности, а также поставляемые артефакты и стандарты, которые они собираются охватить. Они работают, исходя из своих убеждений, уделяя первостепенное внимание некоторым особенностям данного конкретного проекта. Все это должно наилучшим образом подходить людям, которые заняты в работе над проектом, и их культурным характеристикам.
В этой статье мы рассмотрим то, как эти идеи были применены в ряде проектов с различным количеством разработчиков, использовавших разные технологии.
Краткое содержание
Как только мы пытаемся разобраться, "из чего же состоит методология", сразу становится понятно, что методологий должно быть много. При этом для каждого конкретного проекта "оптимальной" будет одна какая-то методология. Более того, все люди обладают разными склонностями, которые обусловлены их жизненным опытом, страхами и принципами. При выборе методологии особое внимание нужно уделять трем основным факторам: размеру команды разработчиков, критичности проекта для компании и его приоритетности. Помимо этого, на результат будут оказывать влияние как культурные ценности команды, так и индивидуальные характеристики ее членов. В этой статье описаны структура и опыт использования этих принципов в проектных разработках.
Методология и ее автор
"Любая методология основывается на страхе", - написал как-то Кент Бек в одном из обсуждений методологий. Поначалу это замечание показалось мне малозначительным, но потом я понял, что в большинстве случаев, оно совершенно справедливо. Каждый элемент методологии призван предотвратить появление тех проблем, с какими автор методологии уже сталкивался в прошлом. Боитесь, что программисты сделают в коде много ошибок? Не забывайте о проверках кода. Вам кажется, что заказчики сами не знают, чего им надо? Создавайте прототипы пользовательских интерфейсов. Опасаетесь, что проектировщики уйдут в самый разгар работы? Сделайте так, чтобы они писали подробную документацию всего, что делают. Если бы методологи могли (или хотели) явно обозначить свои основные страхи и пожелания, цель методологии была бы ясна с первого же взгляда.
И, наконец, в качестве последней составляющей характеристики методологии, мы должны упомянуть индивидуальную философию ее автора. Эта философия оформляется в процессе приобретения автором личного опыта, а также экстраполяций, сделанных на основе этого опыта. Чтобы методология "подошла" определенному проекту, она должна соответствовать философии и страхам как команды разработчиков, так и самого автора методологии.
Мой опыт в различных проектах
В Центральном Банке Норвегии работает около 40 штатных программистов и вполовину меньше контрактников, и надо сказать, им приходится решать на удивление много разнообразных задач.
В то время, когда я там находился, основным проектом был проект Y2K, в котором было занято 35 человек. Главной целью здесь являлось предотвращение крушения банковской системы Норвегии, которое могло состояться 1 января 2000 года. Критичность проекта соответствовала "потере невосполнимой суммы", главными приоритетами были своевременность и корректность проекта. Основополагающей технологией являлись традиционные большие ЭВМ.
В то же самое время шла работа над другим, внутренним проектом, который заключался в создании программы для банковского персонала. Она включала в себя возможность заказывать обед в кафетерии и отслеживать статус сделанных заказов - и все это в виде веб-приложения. Над этой задачей работало один-два человека, которые использовали Delphi или Java и Интернет-браузер. Критичность проекта соответствовала "потере комфорта", приоритеты - сделать быстро и без особых затрат.
Та же группа программистов несла ответственность за работу над системой, которая должна была собирать и проверять все данные о межбанковских транзакциях в стране, причем эти разработки велись вместе с еще одной компанией. В проекте, который я сейчас опишу более подробно, тоже использовались большие ЭВМ.
Один программист использовал язык SQL для формирования различных обобщающих отчетов, касающихся инвестиций и затрат. Еще один проект был начат для того, чтобы заменить существующие системы, работающие на больших ЭВМ, на распределенные системы, использующие Интернет-технологии, объектно-ориентированный подход и компонентную архитектуру, построенную на базе CORBA/Java. Были еще и другие проекты, но я думаю, что упомянул уже достаточно, чтобы читатель получил общее представление о ситуации. Как мне кажется, в подобном случае невозможно говорить о какой-то одной методологии, которая была бы "правильной" для всего этого разнообразия задач и проектов.
Что касается меня, то я работал над проектом, связанным с межбанковскими транзакциями, а также над внутренним Интернет-проектом для отслеживания заказов. Первый из них был особенно интересен, так как за время работы над ним его пришлось дважды "передвигать" из одной клетки нашей "методологической решетки" (рис. 5) в другую.
В ноябре мне сказали, что этот проект рассчитан на 15 рабочих недель, что всего в разработках участвует 3 человека, что дизайн программы уже практически завершен, и что у людей есть сходный опыт работы над предыдущей версией системы. Исходя из изложенной выше схемы методологий и моего собственного опыта, я предположил, что этот проект соответствует позиции D4 на схеме, а это означало, что трем разработчикам следует создавать систему просто работая сообща, обращая минимум внимания на всякие бюрократические штучки (нашей стандартной фразой было: "сделай свою работу и иди домой"). Впрочем, вскоре оказалось, что вся задача была оценена приблизительно, и к тому же, только частично. Мы провели дополнительные вычисления, и оказалось, что этот проект должен быть рассчитан на 130 рабочих недель. Кроме того, мы пересмотрели идею насчет того, что все три программиста могут работать в разных городах. В процессе работы использовались новые технологии, требовалось внедрение новой, более чувствительной схемы обработки ошибок, система должна была работать в реальном времени, и вдобавок обнаружились проблемы со взаимоисключающим доступом внутри основной базы данных. Кроме того, выяснилось, что им нужно еще и работать вместе с другой командой, которая находилась в другой части города. Ведущий архитектор через два месяца уходил в отпуск по уходу за ребенком, руководитель проекта не имел опыта работы ни в IT сфере, ни в руководстве проектами, а между тем, отчетность по проекту должна была осуществляться на высоком государственном уровне.
В этот момент я решил перевести наш проект в категорию E5. Это означало переход к инкрементным разработкам, планированию выпусков системы с минимальным риском, еженедельные телеконференции всей группы разработчиков, ежемесячный доклад о положении дел и т.д. Первая итерация прошла в начале февраля, и прошла в срок.
Однако сразу после этого ушел в отпуск архитектор, одного из ведущих программистов перебросили на проект "по борьбе с ошибкой 2000 года", а мы обнаружили ошибку в проектных решениях, отвечающих за восстановление после ошибочных ситуаций и за контроль над взаимоисключающим доступом. Теперь на наш проект отвели уже десять человек, большинство которых не имело опыта работы в данной области, к тому же работали в совершенно разных местах. Обычные каждодневные встречи и общение были попросту невозможны.
В середине февраля я решил, что проект пора переводить в категорию E15. Мы разработали более подробный план поставок для каждого разработчика, запустили программу моделирования тестов, стали уделять большее внимание общению с каждым из группы разработчиков. Из-за нехватки времени мы не стали предписывать членам команды делать еще и бумажную работу, а предложили перевести все в рамки личного общения - бесед по телефону, телеконференций и поездок друг к другу на поезде. Уже через месяц персоналу удалось наладить свою работу, стабилизировался и план. Наконец-то вся история пришла к своему счастливому завершению. Мы сумели обнаружить все серьезные ошибки в дизайне на ранней стадии работ. Наш новый руководитель проекта сумел найти общий язык со своими подчиненными и хорошо отслеживал запланированные выпуски программы. Проект был закончен вовремя через год - в феврале. Все руководители были довольны как технической стороной проекта, так и по той причине, что общий план выпуска системы не изменился даже после мартовского пересмотра проекта.
В этом проекте я впервые на практике применил схему с рис. 5 и с ее помощью последовательно менял методологию прямо в ходе проекта. Впрочем, неосознанно я пользовался всеми этими принципами и схемами, начиная с 1994 года. Вот еще несколько примеров, которые я привожу в порядке возрастания размеров проекта:
Интернет-проект по отслеживанию заказов в кафетерии относился к категории C4, иначе говоря, "самых дешевых" проектов.
В нем не было никакой письменной документации, за исключением нескольких набросков вариантов использования. Вся работа проходила в совершенно неформальной обстановке, вплоть до того момента, когда было принято решение не разрабатывать эту систему самим, а купить уже готовый продукт (все в соответствии с приоритетами экономичных проектов). Проект Центрального банка Норвегии под названием BankLab представлял собой разработку прототипа для будущей критически важной банковской программной системы. Его можно отнести к категории С5: всю команду разработчиков посадили в одной комнате и постарались избавить от любых помех в работе. Руководитель и ведущий программист пришли к единому мнению относительно того, что привело проект к успеху: "Возьмите хороших специалистов, работайте небольшой командой, поместите всех в одну комнату, обеспечьте их необходимой информацией, а потом не мешайте". (Как сильно все это отличается от атмосферы работы над проектом Y2K в этом же банке!) Как я уже говорил, в проекте Chrysler Comprehensive Compensation (C3) использовалась методология "Extreme Programming". Они заменили всю письменную документацию непосредственным общением, рисованием у доски, индексными карточками и усиленным регрессионным тестированием. Были также и другие нововведения, которые подробно описаны в [XP, C3a, C3b, Beck99]: постоянная смена партнеров при парном программировании и поставки очередных версий системы каждые три недели. Если оперировать понятиями, которые мы ввели в этой статье, то они использовали те принципы, которые позволили натянуть методологию D6 на проект размера D14, и, таким образом, снизить расходы и повысить продуктивность. Проект под названием "Winifred" разрабатывался с использованием языка Smalltalk. Он попал в категорию D40, его главным приоритетом было "сделать в срок". Вся команда разработчиков размещалась в одном месте, внутренние коммуникации были на высоте. Ход работ над проектом и методология задокументирована и опубликована в [Cockburn98].Я упоминаю этот проект в данном контексте, поскольку выбор методологии основывался на размере команды, близости рабочих мест, а также приоритетах и критичности самого проекта. Все эти факторы привели к увеличению роли непосредственного межличностного общения. Проект "Rishi" (язык Smalltalk) попал в категорию D90. Конечно, мы старались работать в максимально "легком" стиле, однако даже при этом нам понадобилось несколько команд проектировщиков. В этом проекте мы ввели специальную систему координирования работы внутри команды, куда входили различные собрания и документы.
Принципы
Существенную роль в поисках нужной методологии играет определение принципов, по котором ее можно было бы разработать. После создания полудюжины различных методологий и проведения нескольких дюжин опросов и интервью разнообразных проектов, я сумел определить четыре основные принципа, которые и представляю вашему вниманию. На сегодняшний день я могу сказать, что практически уверен в справедливости любого из них. Ниже мы рассмотрим их использование.
Принцип 1. Большая по размерам методология нужна тогда, когда в проекте занято большое число разработчиков.
"Большей по размерам" я называю ту методологию, в которой содержится большое количество элементов. Поскольку главное предназначение любой методологии - координировать работу людей, то следовательно, чем больше проект, тем "больше" должна быть и используемая в нем методология. Объем методологии возрастает пропорционально числу ролей и типов рабочих продуктов. [Harrison96].
Этот принцип не позволит нам рассчитывать, что методология, которая хорошо зарекомендовала себя в маленькой команде, будет так же хорошо работать и в большой. Кроме того, он указывает на то, что не стоит употреблять методологию, рассчитанную на большую команду разработчиков, если над проектом работает небольшая группа программистов.
Принцип 2. Большая корректность методологии (видимая со стороны) или, другими словами, "большая плотность" нужна в тех случаях, когда скрытые ошибки в программном продукте могут повлечь за собой значительный ущерб (большая критичность разрабатываемой системы).
Я классифицирую программные системы по следующим категориям возможного ущерба (разумеется, этот список можно расширить):
Потеря комфорта в работе означает, что при поломке системы люди будут вынуждены больше работать вручную или же идти друг к другу для разговора, чтобы устранить помеху в коммуникации. Представьте, например, что ломается система, контролирующая процесс купли-продажи, или же программа, поддерживающая корпоративную инфраструктуру.
Потеря несущественной суммы означает, что утрата денежных или других сходных по значимости ценностей приносит компании некоторые неудобства, но не более. К этому типу можно отнести неправильную выплату зарплаты или неверные платежи по счетам (все это можно исправить вручную).
Потеря невосполнимой суммы означает, что утрата денежных или сходных по значимости средств фактически эквивалентна банкротству компании. В эту категорию можно отнести программные системы национальных банков и т.п.
Потеря жизни означает, что в результате ошибки в программе могут погибнуть люди. К этой категории относятся предприятия, работающие на атомной энергии, проекты, связанные с космосом, системы управления полетами самолетов и т.д.
Согласно этому принципу, дополнительные затраты на более тщательную защиту от ошибок вполне могут себя оправдать - в зависимости от того, в какой из четырех вышеперечисленных категорий находится проект.
Поломка на атомной станции гораздо серьезнее, чем, например, поломка в моей программке, которая отслеживает течение матча по боулингу. Следовательно, при создании программных продуктов для атомной станции можно позволить себе использовать более трудоемкую и дорогую методологию. В этом случае, методология будет содержать большее количество различных элементов, причем эти элементы будут иметь большую "плотность".
Допустим, в обоих проектах используются варианты использования (use cases). Ребята из Лиги по боулингу вполне могут написать их в виде нескольких предложений на салфетке или на доске и считать это достаточным документом. Команда, которая строит атомную станцию, наверняка будет настаивать на том, чтобы все варианты использования были написаны с помощью специального инструментария, чтобы были заполнены все необходимые поля и т.д. После они обязательно потребуют пересмотра, внесения правок и многократного подписания документов в течение жизненного цикла проекта. При этом стоимость вторично написанных вариантов использования возрастает. Однако преимущество этого метода состоит в том, что чем большее количество "писателей" и "читателей" будут взаимодействовать между собой, тем меньше вероятность возникновения ошибок и недопонимания.
Возрастающая стоимость разработок вполне оправдывается большей безопасностью и надежностью конечного продукта.
Принцип 2 указывает на то, что есть ситуации, когда дополнительные расходы на разработку оправдывают себя. И это хорошо, поскольку следующий Принцип, за номером 3, гласит, что более "тяжелая" методология ложится тяжким бременем на бюджет проекта.
Принцип 3. Незначительное увеличение "размеров" или "плотности" методологии ведет к существенному увеличению стоимости проекта.
Приостановка работы одной команды программистов для координации с другой командой требует не только дополнительного времени, но и дополнительной концентрации (см. обсуждение "потока" у ДеМарко [DeMarco99] и Коуберна [Cockburn98]). Для обновления документации, относящейся к требованиям, дизайну системы и тестированию, тоже понадобится немало времени.
Этот принцип справедлив для любого проекта. Как вы уже заметили, мы не обсуждаем, выгодны или не выгодны компании дополнительные затраты - здесь затрагивается исключительно вопрос стоимости, не более. Проблема определения сообразности дополнительных расходов относится к Принципу 2.
Итак, мы подошли к точке, когда уже можно обсуждать отношения между размером методологии, проекта и задачи. Делать это довольно непросто, потому что существует тенденция считать, что чем больше задача, тем больше нужно людей для ее выполнения.
Размеры проекта и методологии связаны между собой положительной обратной связью. Если над проектом работает сравнительно немного людей, то им нужна сравнительно небольшая методология. Чем меньше "весит" методология, тем продуктивнее работает команда. А чем продуктивнее работают люди, тем больше задач они могут решать - иначе говоря, маленькая команда разработчиков, использующая "легкую" методологию, вполне способна решать крупномасштабные задачи.
С другой стороны, когда в проекте участвует большее количество людей, их работу сложнее координировать, т.е. нужна более "тяжелая" методология.
Такая методология будет снижать их продуктивность, поэтому для выполнения задачи понадобится большее число разработчиков. Впрочем, размер методологии растет медленнее, чем размер проекта, поэтому в какой-то точке можно прийти к такой ситуации, когда команда будет справляться с поставленными задачами, и менеджмент будет успевать координировать работу программистов (при условии грамотного и здравого управления процессом, разумеется).
Именно поэтому (см. Рисунок 3) для решения конкретной задачи вам понадобится меньше людей, если вы будете использовать легкую методологию, и больше - если тяжелую. Впрочем, существует ограничение по размеру задачи, которую может решить данное число людей. У большой команды, использующей тяжелую методологию, этот "порог" выше, чем у маленькой команды, которая использует легкую методологию. Таким образом, если ваша задача выходит за рамки такого ограничения, то вам придется, с одной стороны, увеличивать количество разработчиков и, с другой, использовать более тяжелую методологию.
Рисунок 3. Объем задачи и методологии непосредственным образом влияет на количество персонала в компании.
Главная трудность состоит в том, что практически невозможно точно определить объемы задачи в самом начале проекта, а следовательно, и минимальное число людей, которые могут эту задачу решить. К тому же, количество разработчиков напрямую зависит от того, какие конкретно люди будут работать над проектом.
И наконец, если размеры проекта возрастают, может оказаться, что оптимальным решением будет применить другую методологию.
Завершившийся не так давно проект С3 (Chrysler Comprehensive Compensation [C3a, C3b]), может служить убедительным примером всего, о чем я сейчас говорил. После того, как 26 человек не смогли выполнить задачу по созданию системы, которая считалась "большим проектом", за дело взялась малая часть этой команды - всего восемь человек. Используя новую, максимально легкую, но при этом строгую методологию [XP], они начали проект с нуля и уже через год смогли завершить то, что не смогла сделать большая команда, применявшая тяжелую методологию.
Можно с уверенностью сказать, что частично такой успех методологии ХР был обеспечен последним, четвертым Принципом.
Принцип 4. Наиболее эффективная форма коммуникации (для передачи идей) - непосредственное взаимодействие, лицом к лицу, как при рисовании у доски.
Принцип 4 гласит, что разработчикам, которые сидят друг возле друга и могут свободно общаться, легче создавать программный продукт, то есть, затраты на разработку этого программного продукта будут меньше. Это также означает, что если проект растет таким образом, что обеспечить непосредственную коммуникацию между разработчиками уже не удается, ее эффективность будет падать, а значит, возрастут связанные с ней затраты.
На рисунке 4 изображена кривая, которая показывает, как падает эффективность коммуникации при переходе от непосредственного общения у доски к разговору по телефону, интерактивной переписке (чату и т.п.), видеозаписям, и, наконец, к документации на бумаге. Чем ниже находится кривая, тем меньше у разработчиков возможности общаться между собой, исчезает мультимодальность коммуникации, возможность передавать информацию с помощью интонации, задавать вопросы по мере их возникновения.
Рисунок 4. Эффективность коммуникации
Однако это "правило коммуникации" вовсе не означает, что любой программный продукт должен быть разработан несколькими людьми, сидящими в одной комнате. Автор методологии должен знать, что если первоочередными факторами являются продуктивность и стоимость программных разработок, то необходимо уделить особое внимание работе небольшими командами и непосредственному общению между сотрудниками (как, например, это сделано в Extreme Programming [XP]). Этот вывод подтвержден исследованиями [Plowman95]. Кроме того, в работе Силлинса [Sillince96] приводится обсуждение различных аспектов коммуникации внутри одной организации.
Приоритеты
При всем при этом немалое значение в выборе методологии играет желание спонсоров проекта: хотят ли они получить программный продукт быстро, с минимальным количеством дефектов, или же им нужно наблюдать за процессом во всех его проявлениях. Разным приоритетам соответствуют разные методологические рекомендации.
В некоторых методологиях приоритеты заметны сразу, в некоторых нет. Так, например, объектно-ориентированная методология Мартина и Оделла [Martin96] достаточно общая и подходит для многих случаев, однако не совсем понятно, на что конкретно она направлена, и можно ли менять эту "направленность" для работы над различными проектами. Семейство методологий OPEN [BHS97], по всей видимости, основной целью полагает корректность программных продуктов, явность и повторяемость процесса. Методология под названием The Personal Software Process of Humphreys [Humphreys97] была разработана для обеспечения предсказуемости работ.
В трех последних методологиях о приоритетах говорится открыто: авторы семейства методологий Crystal [Cockburn98, Crystal] и Extreme Programming [XP, Beck99] заявили, что их методологии направлены, в первую очередь, на повышение продуктивности и снижение стоимости работ. При этом они все же отличаются друг от друга - Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология "Adaptive Software Development", детище Джима Хайсмита [Highsmith], разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках).
Любая методология состоит из десяти
Любая методология состоит из десяти основных элементов: ролей, навыков, видов деятельности, используемых техник, инструментария, поставляемых артефактов, стандартов, мер качества и приоритетов проекта. Главным результатом моей работы, который я обобщил в этой статье, стало обязательное наличие многих разнообразных методологий. В зависимости от размера проекта (числа людей, работу которых необходимо координировать), критичности разрабатываемого приложения и основных приоритетов, в проекте могут применяться различные методологии. Для любой точки в пространстве размер/критичность создатели методологии выбирают определенный ряд аспектов (роли в проекте, виды деятельности, поставляемые продукты и стандарты) и пытаются минимизировать риски, связанные с некоторыми качествами проекта. При этом они базируются на своем личном опыте, к которому относятся также их намерения, страхи и философские воззрения. При сравнении различных методологий необходимо учитывать все эти моменты, а также их соотношения с нуждами проекта или организации.
Мы выяснили четыре основных принципа проектирования методологии. Вкратце их можно описать следующим образом:
чем больше команда, тем "тяжелее" должна быть используемая методология;
увеличивайте "плотность" методологии при увеличении критичности проекта;
чем "тяжелее" методология, тем выше стоимость проекта;
самая эффективная форма коммуникации - непосредственное общение.
Все эти принципы нашли свое подтверждение во время работы автора над различными проектами, однако нам известно очень мало других исследований на данную тему, хотя разработка данного вопроса представляется очень актуальной.
Для чего нужны модели
Прошло уже почти 20 лет со времени появления в 1986 году вызвавшей множество споров статьи Фредерика Брукса «Серебряной пули нет». В данной работе автор предрекал, что в течение ближайшего десятилетия с момента её выхода не возникнет методов, использование которых позволит на порядок величин повысить производительность разработки программного обеспечения. Эта статья вызвала множество споров и работ с опровержениями, и в 1995 году Ф. Брукс опубликовал ответы на некоторые из критических замечаний [1].
По признанию самого Ф. Брукса наиболее тщательный анализ его статьи был предпринят Дэвидом Харелом в работе «Кусая серебряную пулю» [2]. Д. Харел рассматривал «Серебряной пули нет» как чрезмерно пессимистическую и намеревался высветить в своей работе более яркую сторону проблемы, предпосылая статье подзаголовок «К светлому будущему программных разработок». Им была предложена унифицированная система разработки программного обеспечения, главной целью которой было освободить программиста от необходимости рассуждать на чрезмерно глубоком уровне детализации, предоставить возможность размышлять над решением проблемы и представлять свои идеи при помощи соответствующей высокоуровневой нотации, а именно моделей. «Использование подходящего графического формализма может оказать впечатляющий эффект на инженеров и программистов» [2]. Кроме самих моделей для эффективной работы необходимы средства для их изучения и анализа, среди которых одной из наиболее полезных, по мнению Д. Харела, является возможность исполнения модели.
В настоящее время всё чаще упоминается метод разработки на основе моделей или Model Driven Development (MDD) [5], обещающий стать первым технологическим скачком со времён появления компиляторов, который сможет значительно ускорить процесс создания программного обеспечения и улучшить его качество. Лидирующие позиции в данной области призван занять стандарт Model Driven Architecture (MDA), разработкой которого занимается консорциум OMG. Разработка в рамках MDA предполагает, что сначала создаётся одна или несколько абстрактных моделей системы, которые далее проходят несколько стадий автоматизированной трансформации в более детальные модели и, в конечном итоге, преобразуются в код на языке программирования.
Как проще написать одну строку на Java, чем 10 строк на языке ассемблера, так же проще построить графическую модель на языке UML, чем писать на Java, считают сторонники подхода MDA. Но для успешного применения моделей необходима не только удобная нотация для их записи, которую предоставляет язык UML, но и соответствующий инструментарий для их изучения.
Автоматизация разработки является тем технологическим средством, которое должно привести к ускорению процесса создания программного обеспечения и повышению его качества. Тем не менее, ранние попытки применения автоматизации в сфере моделирования ограничивались лишь поддержкой в создании диаграмм и генерацией скелетного кода, что было недостаточным для того, чтобы существенно увеличить производительность разработки. Наибольшей же отдачи от MDD можно добиться лишь после полной реализации его потенциальных возможностей для автоматизации, которые включают: автоматическую генерацию полного программного кода по моделям (а не скелетного кода или отдельных фрагментов), автоматическую верификацию моделей (например, при помощи их исполнения).
Данная статья посвящена теме исполнения моделей. Автоматическая верификация подразумевает возможность при помощи компьютера определить, удовлетворяет ли модель требованиям, предъявляемым к системе. Такая проверка может принимать различные формы, включая формальный математический вывод, но наиболее часто под этим подразумевается тестирование и отладка моделей путём их исполнения. В любом случае важно иметь такую возможность для моделей, находящихся на высоком уровне абстракции и даже неполных, которые появляются на ранних стадиях процесса разработки, поскольку именно тогда и принимается большинство фундаментальных решений.
Генерация автоматной модели
Многие современные реализации исполняемых моделей базируются на синтезе автоматов. Далее конечные автоматы можно интерпретировать непосредственно или использовать для последующей генерации кода. Применение автоматов в данном случае обусловлено следующими их преимуществами: они представляются в хорошо формализованном виде, имеется развитый математический аппарат для работы с конечными автоматами, который позволяет проводить над ними формальные исследования и преобразования, и, наконец, автоматные модели довольно хорошо отображаются в код на целевых языках. Но важно подчеркнуть, что хотя автоматные модели являются хорошо формализованным и мощным средством спецификации, они могут оказаться сложнее в работе и менее наглядными для неподготовленных пользователей, чем другие модели. Кроме того, при рассмотрении программной системы возможен разрыв, связанный с различиями в степени абстракции, используемой в автоматных и других спецификациях.
Рисунок 2: использование автоматов
Следует отметить, что при исполнении моделей при помощи автоматов появляются дополнительные трудности при реализации визуализации исполнения. Дело в том, что исполнению подвергается уже не сама модель, а её представление в виде автоматов или даже код на языке программирования, а отображать изменения необходимо в терминах самой модели. Таким образом, по сравнению с непосредственной интерпретацией моделей, в данном случае необходимо прилагать дополнительные усилия для определения соответствия конструкций, употребляемых в моделях, и их образов в автоматах и коде.
Интерпретация
В данном случае для исполнения модели создаётся специальная программа, называемая интерпретатором. На вход интерпретатору подаётся сама модель в том виде, в каком она была создана пользователем, без каких либо промежуточных преобразований. Основным недостатком интерпретации является её низкая скорость.
Рисунок 1: интерпретация
На рисунке 1 представлена схема исполнения моделей с использованием непосредственной интерпретации.
Исполнение моделей при помощи виртуальной машины
Буздин К.В.
Труды Института Системного Программирования РАН, 2004 г.
Литература:
[1] Брукс Ф. Мифический человеко-месяц или как создаются программные системы. — Пер. с англ. — СПб.:Символ-Плюс, 2001. — 304 с.: ил.
[2] Harel D. Biting the silver bullet: Toward a brighter future for system development // Computer. — 1992. — Jan. — P. 8-20.
[3] ITU-T Recommendation Z.120 Message Sequence Charts (MSC).
[4] Ladkin P. B., Leue S. What do Message Sequence Charts mean? // Formal Description Techniques VI, IFIP Transactions: Proc. of the 6th Intern. Conf. on Formal Description Techniques / Ed. by Tenney R. L., Amer P. D., Uyar M. U. — Boston, 1994. — P. 301-316.
[5] Selic B. The Pragmatics of Model-Driven Development // IEEE Software. — 2003. — Vol.20, No.5. — P. 19-25.
document.write('');
| This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009 |
 |
|
| Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. |
Параллельное исполнение
При комплексировании работы виртуальных машин могут возникать ситуации, когда нужно организовать их параллельное выполнение. Это может потребоваться, например, в случае необходимости рассмотрения всех альтернатив сразу. Кроме этого, некоторые языки моделирования имеют в своём составе специальные конструкции для обозначения того, что элементы модели должны работать параллельно.
Для организации параллельной работы нескольких виртуальных машин можно использовать механизм потоков (thread), предоставляемый многозадачными операционными системами. В этом случае каждая виртуальная машина запускается в отдельном потоке.
Если же существует необходимость организации более детального контроля над параллельной работой виртуальных машин, то можно вручную организовать их псевдопараллельное выполнение. В этом случае в качестве единицы работы отдельной виртуальной машины можно использовать её команды. Каждая из параллельно работающих машин поочерёдно получает право сделать один шаг, после чего она возвращает управление. Для реализации этого можно использовать менеджер, содержащий список всех параллельно работающих машин и раздающий им право сделать очередной шаг на основании выбранной стратегии.
Если в системе реализованы вызовы одной виртуальной машины из другой, то при получении машиной права сделать очередной шаг возможны два варианта:
1. Не существует машины, вызванной из данной машины. В этом случае машина выполняет одну команду из своего программного поля и возвращает управление.
2. Из данной машины
A вызвана машина B, и машина A ожидает её завершения. В таком случае машина A делегирует право сделать очередной шаг машине B. Машина
B выполняет шаг и возвращает управление в машину A, после чего та тоже возвращает управление.
От того, насколько эффективно будет организована работа с моделями, напрямую зависит успех MDD. Один из наиболее удобных и эффективных путей познания пролегает через эксперимент. Именно поэтому исполнение моделей способно значительно улучшить и ускорить их понимание. В данной статье был предложен способ исполнения моделей, основанный на использовании виртуальных машин. Показаны его основные преимущества по сравнению с непосредственной интерпретацией и конечными автоматами, которые широко применяются в данной области. При проектировании системы исполнения моделей, основанной на виртуальной машине, разработчик обладает большей свободой в принятии решений, поскольку команды виртуальной машины создаются исходя из потребностей выбранной предметной области. Этим же обусловлена и простота перевода модели в последовательность таких команд. Кроме того, виртуальные машины обладают широкими возможностями комплексирования.
Почему важно, чтобы модели были исполняемыми
Одним из наиболее важных способов нашего познания является обучение посредством эксперимента. В контексте данной статьи это означает исполнение моделей. Дэвид Харел сравнивает модели, которые не могут быть исполнены, с машинами, у которых нет двигателя. Важным преимуществом исполняемых моделей является то, что они на ранних стадиях обеспечивают возможность получения опыта работы с создаваемой системой. В данном случае уместна аналогия с языками программирования. Когда мы изучаем новый язык, мы всегда бываем очень воодушевлены успешным выполнением первой тривиальной программы “Hello, world!”. Этот простой опыт укрепляет нашу уверенность в правильности действий и служит отправной точкой в дальнейших исследованиях. Информация, полученная в результате экспериментов, помогает перейти от формального знания к пониманию. Путём исполнения модели, отражающей наши ожидания относительно поведения системы, задолго до собственно реализации самой системы мы можем убедиться, что она действительно будет работать правильно. В случае, если при этом будут обнаружены отклонения от ожидаемого поведения, мы можем вернуться к модели, изменить её и запустить тот же сценарий, на котором были выявлены недостатки. Таким образом, исполнение модели позволяет найти ошибки, которые иначе остались бы незамеченными до тех пор, пока большая часть системы уже не была бы реализована, и было бы слишком поздно. И это начинает проявляться сразу же после того, как модель впервые будет запущена на исполнение.
Кроме того, на ранних стадиях создания системы к работе могут привлекаться представители заказчика. В этом случае исполняемая модель будет играть роль прототипа при уточнении требований.
Результат исполнения модели
Результаты, получаемые при исполнении модели, могут быть подразделёны на два вида: получаемые непосредственно в процессе исполнения; получаемые по завершении исполнения.
В первом случае исполнение модели предоставляет возможность получить опыт от общения с реальной системой. При этом допустимо пошаговое исполнение с целью более детальной отладки. При интерактивном исполнении пользователь играет роль окружения системы, он может порождать события, наблюдать и изменять значения переменных, выбирать путь дальнейшего продолжения исполнения, если имеется несколько возможностей. В ответ инструмент поддержки исполнения должен перевести систему в новое состояние. Кроме того, поскольку большинство моделей имеют графическое представление, то изменение состояния должно отражаться на самой модели, например, путём изменения цвета некоторых её элементов. Для получения эффекта непрерывного исполнения интересующую последовательность событий из окружения системы можно подготовить заранее. В таком случае, при наличии соответствующей графической поддержки, можно наблюдать анимацию модели. Аналогичного эффекта можно добиться, если инструмент сам будет генерировать события случайным образом. Также полезна возможность использования точек останова для изучения конкретных состояний моделируемой системы. Особый интерес представляет полное исполнение модели, когда инструмент генерирует все возможные сочетания событий из окружения с целью проверки всех возможных вариантов поведения моделируемой системы. При этом необходима возможность формального описания интересующих разработчика ситуаций и автоматического их распознавания, поскольку результат полного исполнения для реальных систем будет слишком объёмен для исследования его человеком.
В процессе исполнения модели инструмент может собирать различные данные, например, подсчитывать некоторые метрики или составлять трассы, которые представляют собой последовательность событий, возникающих в системе. Подобные данные могут оказаться полезными в дальнейшей работе над системой, например для создания тестов.
Создание виртуальной машины
При создании виртуальной машины для некоторого класса задач необходимо выполнить следующие этапы:
1. Выявить весь объём данных, которые в процессе выполнения задачи могут подвергаться преобразованию. Эти данные образуют поле зрения виртуальной машины.
2. Определить набор команд, который, подобно командам универсальной ЭВМ, будет служить для записи решения конкретной задачи. Этот набор является специфичным для данного класса задач. Последовательность команд из этого набора, определяющая решение конкретной задачи, записывается в программное поле виртуальной машины и не меняется в процессе её функционирования.
3. Реализовать интерпретационный компонент виртуальной машины, представляющий собой совокупность механизмов. Посредством этих механизмов виртуальная машина осуществляет интерпретацию команд, находящихся в программном поле.
4. Реализовать транслятор из внешнего представления модели в последовательность команд виртуальной машины.
Для виртуальной машины должен быть определён способ её использования, то есть:
способ передачи входной информации и формирования начального поля зрения;
способ активизации (запуска) системы;
способ останова системы;
способ извлечения переработанной информации.
Тот факт, что при создании виртуальной машины заданию подлежит набор команд, определяет большее удобство её применения. Для использования автоматов должны быть разработаны методы сведения моделей к автоматам, а решение данной задачи может представлять значительную сложность. В случае же виртуальной машины мы сами имеем возможность взять такой набор команд, который наилучшим образом будет отражать специфику выбранных для исполнения моделей. При этом сам процесс перевода модели в последовательность подобранных таким образом команд не потребует серьёзных усилий. Конечно же, процесс подбора команд должен представлять собой компромисс между простотой перевода моделей в команды и легкостью собственно интерпретации составленных из таких команд последовательностей.
Способы исполнения моделей
Рассмотрим следующие способы исполнения моделей: непосредственная интерпретация, генерация автоматной модели и её исполнение, использование виртуальной машины.
Виртуальная машина
В качестве промежуточного представления для исполняемых моделей могут использоваться не только конечные автоматы. Дело в том, что они представляют собой слишком общий и низкоуровневый инструмент. Конечные автоматы подходят для решения очень широкого круга задач, поэтому в них может не оказаться инструментов, специфичных для выбранных для исполнения моделей. Кроме того, сложность конечных автоматов может резко возрастать при увеличении сложности самой описываемой ими модели [4].
Альтернативной основой для реализации исполняемых моделей может послужить виртуальная машина. Виртуальная машина — это абстрактная машина, для которой существует интерпретатор. В свою очередь, абстрактная машина — это модель процессора, которая не предназначена для реализации «в железе». Для неё определены набор команд и модель памяти. В памяти хранятся данные, с которыми может работать машина. В сравнении с автоматами при создании виртуальной машины имеется большая свобода выбора модели данных.
: использование виртуальной машины
На рисунке 3 схематически представлен процесс исполнения модели при помощи виртуальной машины. Модель подаётся на вход транслятору, который переводит её в набор команд виртуальной машины. Далее интерпретатор осуществляет исполнение команд в заданном пользователем режиме. Кроме того, в процессе исполнения может происходить запись отладочной информации.
При визуализации исполнения здесь, как и в случае использования автоматов, необходимо определять соответствие между конструкциями, употребляемыми в моделях, и их образами в последовательности команд виртуальной машины.
Исследуя рисунки 1, 2 и 3 можно заметить, что и непосредственная интерпретация, и использование автоматов являются частными случаями метода исполнения моделей, основанного на виртуальной машине. Действительно, в первом случае этап трансляции является вырожденным, и внешнее представление модели одновременно образует последовательность команд для интерпретационной компоненты виртуальной машины. Не представляет большой сложности определить набор команд для представления автоматов, в таком случае этап трансляции модели в такую последовательность команд представляет собой ни что иное, как генерацию автоматов по модели. Таким образом, последний из представленных способов исполнения моделей является, очевидно, наиболее гибким.
Виртуальная машина как строительный компонент
Взглянем ещё раз на то, что представляет собой виртуальная машина. Она состоит из некоторого интерпретатора, исполняющего последовательность известных ему команд и имеющего доступ к области памяти для хранения данных. Рассмотрим, что получится, если допустить возможность существования в пределах одного сеанса исполнения нескольких таких интерпретаторов. Поскольку программное поле виртуальной машины остаётся неизменным в течение всего процесса её функционирования, то несколько интерпретаторов могут работать с одной и той же последовательностью команд или каждый иметь свою собственную. Возможна также реализация, в которой различные интерпретаторы будут предназначены для работы с разными наборами команд. Таким образом, задача исполнения модели может быть разделена на подзадачи, для каждой из которых будет создан отдельный набор команд и его интерпретатор со своей моделью памяти. Кроме того, возможен также случай совместной работы нескольких интерпретаторов над общей областью памяти для хранения данных, но, поскольку данные в процессе исполнения модели могут изменяться, такой подход сопряжён с дополнительными трудностями и его использование не всегда оправдано.
Таким образом, набор команд в совокупности с его интерпретатором и моделью памяти образуют своеобразный строительный компонент. Из таких компонентов при создании системы исполнения моделей можно составлять различные комбинации. Остаётся только вопрос о способах комплексирования работы таких компонентов, наибольший интерес из которых представляют два, описанные ниже.
Вызов виртуальной машины
Пожалуй, одним из наиболее полезных способов комплексирования виртуальных машин является вызов одной виртуальной машины из другой. При его реализации вызываемые и вызывающие машины могут как совпадать, так и существенно различаться по своей структуре. В наборе команд той виртуальной машины, из которой происходит вызов, выделяется команда или команды для порождения и вызова другой виртуальной машины. Порождённая машина получает ссылки на своё поле данных и последовательность команд, после чего запускается. Поведение вызывающей машины при этом может варьироваться: либо ожидание завершения вызванной машины, либо продолжение своего выполнения без ожидания завершения вызванной. Следует отметить, что вызовы могут быть многократно вложенными.
Для иллюстрации вышесказанного рассмотрим две возможных реализации вызова виртуальных машин.
1. Виртуальные машины различны, имеют разные наборы команд и различную структуру области для хранения данных. Вызвавшая машина после осуществления вызова блокируется до окончания работы вызванной, после чего продолжает своё выполнение. Такой способ вызова полезен, например, при исполнении моделей на языке MSC 2000 [3], который имеет два уровня: HMSC (high-level MSC) и собственно MSC (message sequence charts — диаграммы последовательности сообщений). HMSC диаграмма представляет собой граф потока управления, в узлах которого помещены ссылки на MSC диаграммы. Таким образом, виртуальная HMSC машина будет являться вызывающей, а MSC машина — вызываемой.
2. Виртуальные машины имеют одинаковую структуру, работают с одним набором команд, но имеют отдельные экземпляры области данных. Вызвавшая машина не блокируется после вызова, а продолжает своё выполнение. Такая организация полезна для обработки альтернатив, которые часто встречаются во многих моделях и призваны отражать различные варианты поведения системы. Допустим, что в процессе своей работы виртуальная машина А1 дошла до такого места, где ей нужно обработать n альтернатив. В этом случае А1 создаёт n-1 своих копий А2, А3, … Аn. При этом копированию подвергается и поле зрения, поскольку предполагается, что до разветвления поведение всех машин было одинаковым. Таким образом, всего приходится по одной машине на каждую альтернативу, и каждая из машин продолжает своё выполнение в пределах назначенной альтернативы. Следует отметить, что с этих пор все машины действуют абсолютно независимо и ничего не знают друг о друге, хотя они и могут разделять один и тот же набор команд. Такой способ может быть применён для обработки альтернатив в языке MSC [3] на HMSC диаграммах и альтернативных выражений на самих MSC диаграммах. Данный пример поднимает ещё один важный вопрос об организации параллельной работы нескольких виртуальных машин.
