Базовые концепции и принципы модели процессов MSF
«Информационная работа – это работа мысли»
Билл Гейтс. «Бизнес со скоростью мысли»
Единое видение проекта
Любой коллективный труд, а тем более такой нетривиальный как разработка и внедрения программного обеспечения, имеет мало шансов на успех, если все участвующие стороны не представляют (или еще хуже не правильно представляют) конечной цели проекта, иначе говоря, не имеют единого видения (shared vision) проекта. Все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат. Всем должна быть понятна цель проекта. Подход MSF не зря акцентирует внимание на этом, казалось бы, умозрительном принципе. На практике не всегда так просто обеспечить единое понимание целей и задач проекта. Зачастую эта единая цель вступает в противоречие с интересами некоторых участников проекта. Или эти участники видят выгоды только от одной подсистемы проекта, которая касается их непосредственно. Например, бывает очень тяжело на последних этапах проекта объяснить сотрудникам склада, зачем им вводить номер накладной на отпущенный товар. Им он не нужен. Зато он нужен бухгалтерии. Конфликт возникает, потому что кладовщики думали, что автоматизируют склад, а не предприятие в целом. Поэтому MSF выделяет в жизненном цикле проекта целую фазу для обеспечения единого видения проекта.
Фаза планирования
Наступает важнейший этап разработки решения. Фаза планирования включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Всё начинается с анализа и документирования проектных требований с разделением их на категории: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования. Затем при создании функциональной спецификации нужно следить за соответствием (traceability) функциональности и существующих требований. Детализация требований происходит по известному всем аналитикам сценарию, прибегая к моделированию вариантов использования, (use - case modeling) и стори-боардингу (story-boarding), хотя у каждого опытного аналитика наверняка есть свой арсенал методов. Затем работа переходит в область проектирования (дизайна), где разрабатываются концептуальный, логический и физический дизайны, служащие уже инструментами для разработчиков. Результаты проектирования документируются в функциональную спецификацию, которая детально описывает вид и поведение всех составляющих решения. На основании спецификации работает команда разработчиков (с учётом синхронизации действий между собой), производится оценивание работ, достигается чёткое соглашение с заказчиком о том, что должно быть сделано. Как только создана спецификация, руководители ролевых кластеров смогут создать детальный план, относящийся к его роли. Примерами планов могут стать: план внедрения, план тестирования, план обучения, план мер безопасности и т.п. Затем проектная группа коллективно анализирует планы и выявляет зависимости между ними. Эти планы в последствии объединяются в сводный план проекта и сводный сетевой график работ. На этом же этапе создается также план управления рисками, к составлению которого есть смысл привлекать всех участвующих в проекте лиц.
Завершается этап вехой «Планы проекта утверждены», на момент которой уже существуют документы: функциональная спецификация, план управления рисками, сводный план и сводный календарный график работ.
Основные задачи проектной группы на фазе планирования:
| Ролевой кластер | Фокус |
| Управление продуктом | Концептуальный дизайн; анализ бизнес-требований; коммуникационный план. |
| Управление программой | Концептуальный и логический дизайн; функциональная спецификация; сводный план и сводный календарный график проекта; бюджет. |
| Разработка | Оценка технологий; логический и физический дизайн; план и календарный график разработки; смета разработки (development estimates). |
| Удовлетворение потребителя | Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility); пользовательская документация/план обучения/график тестирования удобства эксплуатации; обучение. |
| Тестирование | Оценка дизайна; требования тестирования; план и календарный график тестирования. |
| Управление выпуском | Оценка дизайна; эксплуатационные требования; план и календарный график пилотного и окончательного внедрения. |
Верификация технологий
Базовая версия функциональной спецификации создана
Базовая версия сводного плана проекта создана
Базовая версия сводного календарного графика работ создана
Среды разработки и тестирования развернуты
Фаза разработки
Название фазы говорит само за себя. Однако не стоит думать, что все остальные ролевые кластеры проекта на этой фазе могут пить кофе. Все роли принимают активное и деятельно участие в тестировании, выявлении дефектов, анализе удовлетворения нужд заказчика и других задачах в соответствии со своим ролевым кластером. Равно как и сама разработка, очень редко заканчивается этой фазой (да и начинается тоже редко только с этого момента), обычно разработка продолжается и на фазе стабилизации и даже на фазе внедрения иногда приходится что-то править. К моменту завершения этой фазы разработка всех компонент завершена и решение готово к комплексному тестированию.
Задачи ролей во время этой фазы:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Ожидания заказчика. | ||
| Управление программой | Управление функциональной спецификацией; мониторинг проекта; доработка планов. | ||
| Разработка | Разработка программного кода и инфраструктуры; документирование конфигураций. | ||
| Удовлетворение потребителя | Обучение; доработка плана обучения; тестирование удобства эксплуатации (usability testing); графический дизайн. | ||
| Тестирование | Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования. | ||
| Управление выпуском | Чеклисты развертывания (rollout checklists); доработка планов внедрения (включая пилотное внедрение); чеклисты подготовки к внедрению (site preparation checklists). |
Рекомендуемые промежуточные вехи:
Концепция подтверждена
Билд n завершен, билд n +1 завершен…
Фаза стабилизации
На фазе стабилизации фокус смещается в область тестирования и документирования решения. А также создание пилотного внедрения. Результатами этой фазы являются: окончательный продукт (golden release), документация выпуска, материалы поддержки решения, результаты тестирования, проектная документация и анализ пройденной фазы.
Задачи проектной группы на этой фазе:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Исполнение коммуникационного плана; планирование премьеры продукта. | ||
| Управление программой | Мониторинг проекта; приоритезация ошибок. | ||
| Разработка | Устранение ошибок; оптимизация программного кода. | ||
| Удовлетворение потребителя | Доработка эксплуатационных руководств; учебные материалы. | ||
| Тестирование | Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации. | ||
| Управление выпуском | Развертывание и поддержка пилотного внедрения; планирование внедрения; обучение персонала сопровождения. |
Фаза внедрения
Наконец-то. Если проект докатился до этой фазы, то можно считать, что треть пути пройдена... Это конечно шутка, так быть не должно, хотя так бывает довольно часто, особенно если были допущены ошибки на начальных этапах проекта. На этом этапе группа внедряет решение, стабилизирует его и, пробиваясь сквозь противоборство службы сопровождения и поддержки, таки передает решение им, получив одобрение заказчика. И, наконец, получает вожделенный акт. Однако согласно MSF и вопреки реалиям работа группы на этом не заканчивается. Группа работает над сбором метрик и анализом проекта, дабы бесценный опыт, полученный в результате проекта, не канул в дебрях короткой памяти человеческой.
Результатами фазы будут: информационные системы эксплуатации и поддержки, процедуры и процессы, базы знаний, отчёты, журналы протоколов, версии проектных документов, отчёт о завершении проекта, окончательные версии всех проектных документов, описание последующих шагов.
Задачи группы на фазе внедрения:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Получение отзывов и оценок заказчика; акт о приеме выполненной работы. | ||
| Управление программой | Сопоставление рамок проекта с поставленным решением; управление стабилизацией. | ||
| Разработка | Разрешение проблем; поддержка эскалации. | ||
| Удовлетворение потребителя | Обучение; управление календарным графиком обучения. | ||
| Тестирование | Тестирование производительности. | ||
| Управление выпуском | Управление внедрением; одобрение изменений. |
Не нужно также забывать, что после внедрения первой версии продукта, может последовать следующая итерация жизненного цикла.
Фаза выработки концепции
Это первая фаза жизненного цикла проекта. Начинается она с формирования ядра проектной группы (если конечно это первая итерация продукта). Затем закладывается основа, фундамент, будущего решения на основе единого видения проекта (ничем не ограниченное представление о целях и задачах, стоящих перед проектной группой). После этого очерчиваются рамки (чётко описанные задачи, которые предстоит решить), однозначно описывающие то, что предстоит сделать в рамках проектных ограничений, и оцениваются риски. Нельзя смешивать эти два понятия, но и нельзя рассматривать одно в отрыве от другого. Если программист будет создавать продукт, не владея документом единого видения (shared vision document) только на основании описания рамок (scope document), он вероятнее всего не сможет создать то, что ожидает заказчик, ведь основные цели, представления и ожидания заказчика сконцентрированы именно в документе единого видения. Оба эти документа должны создаваться итеративно и тщательно, минимизируя дальнейшие отклонения от них.
Главной вехой этой фазы будет событие «Концепция утверждена». К этому моменту у заказчика и проектной группы уже сформированы устойчивые представления о задачах, функциональности и ограничениях проекта. К моменту этой вехи должны быть готовы следующие документы: общее описание и рамки проекта (vision \ scope document), документ оценки рисков, описание структуры проекта. Задачи проектной группы на этой фазе распределяются следующим образом:
| Ролевой кластер | Фокус | ||
| Управление продуктом | Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта. | ||
| Управление программой | Цели дизайна; концепция решения; структура проекта. | ||
| Разработка | Прототипирование; анализ технологических возможностей; анализ осуществимости. | ||
| Удовлетворение потребителя | Необходимые эксплуатационные характеристики решения и их влияние на его разработку. | ||
| Тестирование | Стратегии тестирования; критерии приемлемости, их влияние на разработку решения. | ||
| Управление выпуском | Требования внедрения и их влияние на разработку решения; требования сопровождения. |
MSF рекомендует обозначить следующие промежуточные вехи в течение фазы:
Ядро проектной группы сформировано
Черновой вариант концепции проекта составлен
Итеративный подход
Весь жизненный цикл проекта протекает в виде последовательности итераций выпуска версий. MSF рекомендует вкладывать в первую версию продукта только базовую функциональность и затем наращивать ее в следующих версиях. Для малых проектов иногда бывает достаточно одной итерации, однако все равно рекомендуется не упускать возможности версионирования т.к. это эффективный инструмент достижения успеха проекта.
Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации. Такой подход позволяет планировать возможности для последующих версий, делать учёт опыта предыдущих циклов, обеспечивая гибкость и устойчивость к переменам требований. Таким образом, обеспечивается ведение «живой» документации, которая изменяется по мере эволюции проекта. В рамках одной итерации все документы (равно как и программный код) тоже развиваются итеративно. Например, план тестирования или концепция проекта (shared vision document) распространяется среди всех ролей проекта в виде «подходов» (approaches) еще до утверждения и затем итеративно эволюционируют благодаря обратной связи участников проекта до формы, подлежащей утверждению. Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями, и часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии. Создание базовой версии всех проектных документов на самых ранних этапах дает возможность всем членам проектной группы осмыслить свои задачи и цели проекта, а так же приступить к работе с минимальными задержками.
Методология MSF рекомендует делать текущие сборки программных компонент решения. Это особенно важно в сложных комплексах, где необходимо учитывать и тестировать совместимость компонент. Для этих целей Майкрософт при разработке своих продуктов выполняет ежедневные билды (daily builds).
Разработка и тестирование ведутся практически одновременно, что увеличивает надежность результирующего кода. Для осуществления такого подхода к разработке необходимо вести управление конфигурациями проекта. Необходим строгий мониторинг и контроль версий программного кода, документации, аппаратных настроек и других артефактов проекта. Управление конфигурациями в свою очередь служит эффективным инструментом управления изменениями в проекте, которое регламентируют процесс внесения изменений в артефакты проекта от запроса на изменение, до включения его в базовую версию. Вот основные рекомендации MSF для выпуска версий решения:
Создавая планы, предусматривайте версионирование.
Прежде всего, поставляйте базовую функциональность.
Выбирайте приоритеты, учитывая риски.
Осуществляйте частые итерации разработки.
Институцируйте процедуры контроля изменений в проекте.
Не создавайте новых версий, если они не увеличивают ценность решения.
Концентрация на бизнес-приоритетах
При создании любого решения необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить потребитель решения. Если проект нацелен на предприятие, то точкой концентрации будет бизнес-отдача (business - value). В отношении персональных программ, как, например, компьютерная игра, отдачу можно выразить в виде эмоционального удовлетворения потребителя. Можно сказать уверенно, что MSF не подходит для волонтёрских проектов, удовлетворяющих чьи-то амбиции или являющихся творческой отдушиной для разработчиков – творцов с рождения.
Матрица компромиссов
Для эффективного достижения компромиссов в течение всего жизненного цикла проекта, MSF рекомендует на начальных этапах зафиксировать приоритеты факторов проекта (ресурсы, время, возможности). На один из факторов влиять в течение проекта будет практически невозможно (Фиксируется), - другой будет обладать некоторым приоритетом при разрешении компромиссов (Согласовывается) и оставшийся будет принят в соответствии с первыми двумя (Принимается).
Зафиксировать приоритеты в проектной документации можно с помощью простых текстовых оборотов: «Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения» или «Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки» и т.п. В дальнейшем возврат к приоритетам может сильно помочь при нахождении компромисса внутри проектной группы (обращаю внимание на то, что представитель заказчика тоже является членом проектной группы).
Модель проектной группы MSF
Вот здесь начинается самое интересное и, на мой взгляд, новаторское в подходе MSF. Этой теме уделена целая «белая книга» из пакета руководств MSF и здесь мы рассмотрим только основные подходы к построению проектной группы. Существуют основные принципы и концепции модели проектной группы, которые во многом являются чуждыми большинству IT компаний. Здесь разрушаются некоторые стереотипы (например, диктаторские полномочия и соответствующая ответственность менеджера проекта) и предлагается несколько иная, более органичная структура организации рабочих групп. Подход, по меньшей мере, весьма интересен.
Проектная группа разделяется на шесть ролевых кластеров, соответствующих шести качественно различным задачам проекта.
Управление продуктом
Управление программой
Разработка
Тестирование
Удовлетворение потребителя
Управление выпуском
Между этими кластерами образовывается устойчивый баланс ответственности и полномочий, позволяющий команде эффективно функционировать. Как я уже упоминал, существуют основные принципы модели проектной группы.
Распределяйте ответственности при фиксации отчетности
Наделяйте соответствующими полномочиями ролевые кластеры.
Таким образом, все ролевые кластеры в команде равноправны . Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды.
Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Что важнее решать вам – о управленец! Однако, по мнению Майкрософт, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца. Перечислю основные области ответственности ролевых кластеров.
| Управление продуктом |
Представление интересов заказчика; аналитика; обоснование бизнес-отдачи; формирование единого видения и рамок проекта; управление требованиями заказчика; определение приоритетов факторов (время/рамки/ресурсы); PR продукта; план коммуникаций. |
| Управление программой | Управление процессом разработки с целью получение продукта в рамках проектных ограничений; формулировка спецификации и разработка архитектуры; управление совещаниями и коммуникациями; формирует сводный план; управление рисками; сетевой график работ; отчётность. |
| Разработка | Определяет дизайн решения; оценка времени разработки; разработка; консультирование. |
| Тестирование | Планирование тестирования; тестирование. |
| Удовлетворение потребителя | Представляет интересы потребителя (на заказчика, а конечного пользователя системы); сбор требований потребителя; формирует требования к эргономике, справочной системе и учебным материалам. |
| Управление выпуском | Внедрение; обеспечение сопровождения; материальное обеспечение и логистика; инфраструктура поставок. |
Рассмотрим каждую из фаз жизненного цикла проекта подробнее.
MSF – философия создания IT-решений или голые амбиции лидера
, Softline Company (Киев)
Статья была опубликована в журнале ИТ-менеджер www.it-manager.com.ua
MSF – симбиоз итеративного и фазового подхода
«Развитие, как бы повторяющее пройденные уже ступени,
но повторяющее их иначе, на более высокой базе
(“отрицание отрицания”), развитие, так сказать,
по спирали, а не по прямой линии; — развитие скачкообразное,
катастрофическое, революционное…»
Подход, основанный на фазах и вехах
Что может быть ближе отечественной АСУшной душе, чем такой подход. Десятилетиями наши системы внедрялись поэтапно. Поковыряли ложкой в тарелке, что-то подправили, подмазали – совещание. Не годиться – на доработку. Подправили – совещание. После пятой фрикции (в лучшем случае) с горем пополам закрыли этап. И так далее. Нет-нет, мы не будем возвращаться в ностальгическое прошлое. Майкрософт не предлагает то же самое, только с перламутровыми пуговицами. В рамках одной итерации, жизненный цикл выпуска версии разбивается на пять фаз (выработка концепции (единого видения), планирование, разработка, стабилизация (тестирование), внедрение). Каждая фаза цикла заканчивается главной вехой (контрольной точкой). Соответственно главные вехи будут иметь названия: концепция продукта утверждена, планы продукта утверждены, разработка завершена, готовность решения утверждена, внедрение завершено. Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых кластеров (разработка, тестирование, внедрение, управление проектом и пр.).
В этой контрольной точке всплывают все противоречия и коллизии, возникшие за период фазы проекта. Хорошей практикой является не откладывание проблем до конца фазы, дабы не тратить время и нервы всех участников совещания в главной вехе (хотя на самом деле совещания может и не быть, а возможно просто рассылка и утверждение документов по электронной почте). В рамках фазы должны присутствовать промежуточные вехи, обозначивающие достигнутые промежуточные результаты. Например, на фазе разработки такими промежуточными вехами могут быть: билд n завершен, билд n +1 завершен и т.д. MSF дает определенные рекомендации (рассмотрены ниже) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вехи.
Поощряйте свободное общение
До сих пор большинство IT организаций ограничивает доступность к информации участников проекта исключительно необходимой для выполнения их работы или хотя бы пытается это делать, порождая недоверие внутри рабочей группы, но те, кому интересно всё равно узнают рано или поздно то, что им интересно. Методология MSF разрушает этот стереотип, поощряя свободное общение внутри проекта. Это заметно сокращает риск недопонимания, возникновения недоразумений и стимулирует максимальный вклад всех участников проекта в общее дело. Стоит заметить, что здесь не идет речь о финансовой или юридической информации, которая априори не может быть общедоступной. Зачастую разработчики не знают о проблемах возникающих у внедренцев, а тестирование не в курсе, что идет уже вторая неделя срыва сроков. Во избежание этого MSF предлагает проведение анализа хода работы над проектом в определённых временных точках, документирование результатов пройденных фаз проекта и обеспечение свободного общения в течение жизненного цикла проекта. Благодаря такому подходу обеспечивается выявление рисков всеми участниками проекта на ранних стадиях, что без сомнения вносит ощутимый вклад в успех решения.
Проявляйте гибкость – будьте готовы к переменам
В отличие от традиционной модели управления проектами, в которой подразумевается четкая формулировка требований на начальном этапе проекта и разработка на основании ТЗ, подход MSF основывается на принципе изменяющихся проектных условий. Проектная группа должна быть готова к переменам и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.
Методология очень интересна, если не
Подытожим. Методология очень интересна, если не сказать больше. Ее можно использовать как эффективный инструмент, подходя к нему с творческой изобретательностью и осмысленностью. Нет, наверное, такой методологии управления, строгое соответствие которой, обеспечит успешность проекта. Не нужно воспринимать MSF как догму или панацею. Можно её адаптировать под свои нужды или использовать только фрагменты или концепции применимые в Вашем проекте.
Например, в качестве дополнительного фактора проекта при поиске компромисса (наравне с ресурсами, временем и возможностями) может выступать безопасность или можно добавить дополнительную промежуточную веху «Контроль безопасности» в конце каждой фазы проекта, если того, конечно, требует ваша проектная среда.
Удачных проектов!
Создавайте базовые версии
Под базовой версией в MSF подразумевается зафиксированное состояние любого проектного артефакта (а лучше всех одновременно) в том числе программный код, план проекта, руководства пользователя, настройки серверов и т.п. В последствии, имея базовые версии, вы сможете эффективно управлять изменениями, вернуться на шаг назад, если это необходимо и выполнять аналитику по завершению проекта.
Треугольник компромиссов
Часто бывает очень полезно изобразить эту зависимость заказчику в виде треугольника компромиссов
После достижения утвержденного равновесия с заказчиком, т.е. на запрашиваемые возможности вы назвали и зафиксировали сроки и смету, любое изменение на одной из сторон треугольника влечет изменение на двух оставшихся. Такой подход служит удобным инструментом для нахождения компромиссов с заказчиком и поможет объяснить суть имеющихся ограничений. Иногда имеет смысл добавлять еще четвертое измерение – качество, за счёт которого можно сэкономить время и ресурсы при неизменных возможностях, хотя, на мой взгляд, это последнее на чём стоит экономить. Однако отечественные реалии диктуют свои законы и не редки случаи, когда важен сам факт внедрения и заниженная планка качества решения (quality bar) всех устраивает. В таких случаях участники проекта должны, по крайней мере, знать об этом, и этот факт должен найти адекватное отражение в проектной документации (например, отсутствие дизайнерского оформления интерфейса или ведения журнала операций пользователя в системе).
Управляйте компромиссами
Наверное, не было еще ни одного менеджера проекта, которому не приходилось бы бороться с разрастанием рамок проекта и, как следствие, с перерасходом средств и затягиванием сдачи. Настоящим искусством менеджера является элегантное нахождение компромисса между ресурсами проекта (людскими, финансовыми и пр.), календарным графиком (временем) и реализуемыми возможностями (рамками).
в чём угодно, но уж
|
"Царь Вызывает антирес Ваш технический прогресс: Как у вас там сеют брюкву С кожурою али без?.. Посол Йес!" Л. Филатов "Сказ про Федота-стрельца..." |
Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление. В руководствах по MSF кроме методов, моделей и концепций встречаются практические советы и приёмы, отнюдь не лишенные рациональности. Структурно пакет руководств MSF разделён на пять документов, так называемых «белых книг», каждый из которых охватывает определенную дисциплину или модель MSF : «Модель процессов MSF», «Модель проектной группы MSF», «Дисциплина управления проектами MSF», «Дисциплина управления рисками MSF» и «Дисциплина управления подготовкой MSF». Эта статья посвящена в большей степени первой книге «Модель процессов MSF», в которой будет рассмотрена модель жизненного цикла IT -проекта, а также базисные концепции и принципы методологии MSF.
Предметной областью рассматриваемой методологии является IT -проект (разработка ПО, внедрение/адаптация уже разработанных систем, разворачивание сетевой инфраструктуры или всё вышеперечисленное в комплексе). На мой взгляд, возможность применения данной технологии возникает в любом проекте, в котором задействовано более 4-6 человек. Итак, на чём же зиждется успех гиганта?
в которых может отсутствовать фаза
Существуют проекты, в которых может отсутствовать фаза внедрения или разработки (например, разработка игры, или адаптация 1С).
В первую очередь реализовуйте рискованные нововведения, минимизируя влияние риска на весь проект.
Деятельность каждой фазы не ограничивается ее рамками, как было уже сказано, разработка продолжается почти всегда.
Длительность фаз может быть совсем не одинакова, как изображено на картинках (суть это замечания взята с текста MSF, я бы в жизни не догадался его написать).
ЧТО ПЕРВИЧНО - ПРОЦЕССЫ ИЛИ ПО? ВАЖНО ОПРЕДЕЛИТЬ КРИТЕРИИ
Когда речь заходит о решении данного вопроса в применении к конкретной организации, то, прежде всего, необходимо определить критерии, в соответствии с которыми выбирается «сценарий» создания АСУП. Очевидно, что эти критерии во многом соответствуют факторам, определяющим объем и подходы к проведению внедрения. Но наиболее значимым критерием, оказывающим максимальное влияние как на состав этапов внедрения, их очередность и процесс создания АСУП в целом, по нашему мнению, является квалификация персонала. Под этим понимается как квалификация собственно (далее персонал организации), так и квалификации участников команды проекта внедрения. Два этих понятия взаимосвязаны, так как персонал организации либо частично, либо полностью может представлять команду проекта внедрения.
ФАКТОРЫ, ВЛИЯЮЩИЕ НА ОБЪЕМ И ПОДХОД К ПРОВЕДЕНИЮ ВНЕДРЕНИЯ
В рамках оценки готовности организации к внедрению проводится анализ ряда факторов, которые, в свою очередь, оказывают влияние на объем внедрения, состав его этапов и их очередность. Среди таких факторов можно выделить следующие:
наличие в организации формализованных и задокументированных бизнесс-процессов;
квалифицированность персонала организации и команды проекта внедрения АСУП;
диверсифицированность организации,
состав участников проектов, реализуемых в организации, и их территориальная распределенность (участников);
наличие в организации базы знаний в виде наработок по предыдущим проектами, классификаторов информации, статистических банков данных и т.д.;
другие факторы.
Перечисленные выше факторы различны по своей сути и влиянию на процесс внедрения ПО и подходы к его проведению. Наиболее значимым из них является квалификация персонала организации, которые в дальнейшем войдут в состав команды проекта внедрения. Чем выше квалификация персонала, тем большую часть внедрения ПО, а значит и создания АСУП, организация может выполнить самостоятельно. В свою очередь, такие факторы, как диверсифицированность организации, территориальная распределенность участников проектов, реализуемых в организации, могут определить содержание и объем работ по пилотному проекту, что повлияет на продолжительность внедрения в целом.
Так или иначе, результат анализа факторов позволит определить степень участия внешней консалтинговой фирмы в реализации проекта создания АСУП. Данная степень может быть:
невысокой. В данном случае консалтинговая фирма выполняет:
поставку ПО;
обучение сотрудников организации и представителей команды проекта внедрения.
высокой. В данном случае консалтинговая фирма выполняет:
обследование организации и разработку технического задания на АСУП;
разработку модели функционирования АСУП;
формирование основных структур кодирования АСУП, в том числе структуры проектов предприятия и т.д.;
поставку программного обеспечения;
обучение сотрудников организации и представителей команды проекта внедрения;
разработку пилотного проекта;
разработку регламентов функционирования АСУП и инструкций для персонала АСУП.
С точки зрения консалтинговой фирмы в первом случае речь идет о таком называемом «быстром внедрении», во втором - о полномасштабном внедрении (Рис. 1).
Рисунок 1. Виды внедрений, в зависимости от степени участия консалтинговой фирмы во внедрении2
Возможны также и промежуточные варианты. В любом случае, на выходе процесса создания внедрения ПО должна быть настроенная АСУП, отвечающая заранее сформулированным требованиям. Кроме того, не стоит забывать, что даже в процессе полномасштабное внедрения персонал организации не остается в стороне. Он должен принимать активное участие в большинстве вопросов, связанных с настройкой будущей системы. Ведь в конечном итоге система управления всего лишь инструмент. И настраивается он именно под организацию, а значит, должен максимально учитывать ее специфику. Это позволит в дальнейшем использовать систему управления для решения стоящих перед организацией задач наиболее эффективно.
КВАЛИФИКАЦИЯ КОМАНДЫ ПРОЕКТА ВНЕДРЕНИЯ
Одно дело определить состав этапов внедрения и их очередность, сформировать предварительный план внедрения, другое дело – его реализовать. Как правило, для создания АСУП формируется команда проекта внедрения (далее команда проекта). Ее состав во многом определяется опять же квалификацией персонала организации. Если она высока, то команда проекта может быть целиком составлена из сотрудников организации. В противном случае в состав команды проекта должны войти, как минимум, представители консалтинговой фирмы. В любом случае, на стадии формирования команды проекта необходимо помнить, что ее квалификация и слаженная работа всех ее участников является одним из важнейших условий успешного создания АСУП. Иными словами, содержание и объемы внедрения определяют требования к участникам команды проекта и их квалификации. Среди этих требований можно выделить такие, как:
для представителей самой организации:
знание внутренних процессов на предприятии и его специфики;
способность донести до персонала организации важность работ по созданию АСУП;
наличие определенных должностных полномочий для продвижения решений, связанных с созданием АСУП;
для представителей консалтинговой фирмы
наличие опыта внедрения подобных АСУП;
умение говорить на языке «заказчика»;
если АСУП предполагается базировать на разрабатываемом/дорабатываемом ПО, то умение правильно интерпретировать требования к ПО в задачи для программистов.
Например, опытная консалтинговая фирма может использовать наработки по предыдущим проектам в виде типовых бизнесс-процессов, использование которых позволит сократить общую продолжительность создания АСУП.
Существуют различные рекомендации по повышению квалификации команды проекта. Например, для осуществления какого-либо проекта может быть привлечена высококвалифицированная управляющая компания, которая принесет с собой собственную автоматизированную или неавтоматизированную систему управления, и заставит организацию стать ее активным участником. В данном случае необходимо всегда помнить, что управляющая компания может рано или поздно уйти, и организация останется без системы управления.
Проект внедрения представляет собой такой же проект, как и все остальные. Соответственно, для его управления подходят все существующие методики в области управления проектами.
Итак, содержание проекта внедрения известно и команда проекта сформирована. Соответственно, можно сформировать структуру декомпозиции работ (далее СДР) по созданию АСУП. Следующим действием должно явиться закрепление ответственных из числа команды проекта за те или иные пакеты работ из состава СДР – формирование так называемой матрицы ответственности. Ускорить выполнение данной задачи можно с использованием программного продукта Project Manager (далее РМ) серии Primavera Enterprise разработчика фирмы Primavera Systems (Рис. 2).
Рис. 2. Матрица ответственности проекта внедрения АСУП
В дальнейшем формируется укрупненный план создания АСУП, за работами которого закрепляются в виде ресурсов участники команды проекта внедрения в соответствии с их ролями в проекте (Рис. 3).
КВАЛИФИКАЦИЯ ПЕРСОНАЛА
Рассмотрим влияние квалификации персонала на создание АСУП. Чем выше ее уровень, тем большую часть внедрения организация в состоянии выполнить самостоятельно. В организациях, обладающих высококвалифицированным персоналом, как правило, деятельность построена на отработанных бизнесс-процессах, позволяющих успешно функционировать в условиях конкуренции. Эти бизнесс - процессы могут быть даже не задокументированны и не формализованы. Но в данном случае это не должно явиться помехой на пути внедрения. Каждый сотрудник знает, за что отвечает, какую информацию и когда должен предоставлять и т.д. Последующая настройка ПО позволит ускорить процессы обработки и передачи информации. Возможно, в дальнейшем потребуется разработать несколько регламентов и инструкций для работы сотрудников в АСУП. Но опять же, за счет высококвалифицированного персонала организация выполнит это самостоятельно. Как правило, объем услуг консалтинговых фирм в подобных внедрениях невелик и ограничивается поставкой и инсталляцией ПО, а также обучением сотрудников организации.
В то же время, если по результатам оценки готовности организации ко внедрению выявляется необходимость участия консалтинговой фирмы собственно в разработке АСУП, то на первом этапе проводится обследование и описание существующих бизнесс-процессов. При этом в качестве объектов обследования в большей степени выступают бизнесс-процессы управления, связанные с предоставлением, обработкой и анализом информации. На следующем этапе производится построение оптимизированных бизнесс-процессов с выделением из них автоматизируемых. На выходе должны быть модель функционирования АСУП, позволяющая:
снизить время на подготовку, передачу и согласование информации за счет устранение ненужных звеньев в данной цепочке;
снизить противоречивость и искажаемость информации;
своевременно получать руководству организации необходимую информацию для принятия управленческих решений.
Только после этого проводится настройка ПО. За кадром остались не менее важные этапы, такие как фиксирование требований к АСУП в виде технического задания, формирование команды проекта внедрения.
Итак, квалификация персонала организации влияет на степень участия консалтинговой фирмы во внедрении. В то же время, от уровня квалификации персонала зависит и объем внедрения. Рассмотрим это на следующем примере.
Как уже было сказано выше, процессы в организации желательно документировать. Для этого рекомендуется использовать два типа документов, такие как регламенты и инструкции. Регламенты описывают процесс взаимодействия различных исполнителей в процессе реализации той или иной управленческой функции в рамках системы управления. Инструкции же описывают либо конкретные действия отдельных исполнителей на рабочих местах в ПО системы управления, либо отдельные операции того или иного процесса. Таким образом, инструкции детализируют регламенты. Как показывает практика, чем выше квалификация персонала, тем в меньшей степени требуется разработка инструкций. И, следовательно, объем работ по внедрению сокращается.
ОПИСАНИЕ БИЗНЕСС-ПРОЦЕССОВ И ПО
С методологической точки зрения, для успешного функционирования системы управления разработка бизнесс-процессов должна предшествовать настройке ПО. Отработанные и регламентированные бизнесс-процессы во многом сами по себе гарантируют слаженную работу предприятия, образуя некую внутреннюю системы управления. Каждое подразделение выполняет свои функциональные обязанности, предоставляя информацию руководству для принятия управленческих решений и координации работы предприятия. Дальнейшая автоматизация ряда рутинных бизнесс-процессов за счет использования ПО лишь позволяет дополнительно ускорить их выполнение.
В связи с этим большим заблуждением является мнение, что ПО может решить все внутренние проблемы на предприятии. А, как правило, причины этих проблем заключаются в отсутствии бизнесс-процессов, отвечающих существующим требованиям рыночных отношений. Находясь под влиянием такого подхода, руководители не уделяют должного внимания анализу и оптимизации существующих бизнесс-процессов на предприятии. В результате ПО выходит на первый план и автоматизируется существующий «беспорядок». Процессы управления, несмотря на то, что уже автоматизированные, по сути остаются прежними. Как следствие, руководство предприятия не получает ожидаемой отдачи от АСУП.
Особенно важную роль описание бизнесс-процессов играет в случае создания АСУП на базе разрабатываемого ПО, или если в рамках создания АСУП предполагается осуществление интеграции между различными информационными системами. В первом случае крайне необходимо разработать бизнесс-процессы, максимально отвечающие требованиям к АСУП, так как от этого будет напрямую зависеть эффективность использования ПО. Во втором случае без описания процессов, заложенных в две смежные интегрированные информационные системы, и процесса обмена информацией между ними, практически невозможно приступить к разработке интеграционного модуля. И в том, и в другом случае качество описания процессов закладывает фундамент под дальнейшие работы по разработке ПО или интеграционных решений, внося свой вклад в эффективное функционирование АСУП в целом.
Внедрение систем управления. Что вначале - процессы или ПО?
К.В. Халимов, ЗАО "ПМСОФТ",
М.В. Резник, ЗАО "ПМСОФТ"
В последнее время все большее
В последнее время все большее число предприятий осознают необходимость создания автоматизированных систем управления проектами (далее АСУП). При этом первым и необходимым условием для успешной реализации проекта создания АСУП является наличие у руководства организации заинтересованности в будущей системе и четкого понимания целей, для достижения которых она создается. Это значительно упростит процесс формирования требований к системе.
Создание любой АСУП в организации связано с решением ряда основных задач, таких как выбор программного обеспечения (далее ПО), его поставщика и внедрение ПО. При этом последняя задача является наиболее трудоемкой и значимой в рамках процесса создания АСУП. Для ее успешного решения очень важно на стадии подготовки к внедрению оценить, насколько организация готова к его проведению и по возможности сформировать предварительный перечень этапов внедрения. Это поможет составить представление об объеме будущих работ. Результатом оценки является принятие решения о начале внедрения или временной задержке в его проведении, и определение степени участия внешней консалтинговой фирмы в его реализации.
Литература
Jim Johnson. «Chaos: The Dollar Drain of IT Project Failures. Application Development Trends», January 1995. Standish Group.
Брукс Фредерик, "Мифический человеко-месяц, или Как создаются программные комплексы", Пер. с англ., СПб., Символ-Плюс, 1999.
Richie O'Bower, «Programming as the best creative specialty», 1997. (русский перевод Сергей Кашменский, 1999 года).
Журенков К. «Аутизм -- болезнь ХХI века?» (http://www.ogoniok.com/win/200122/22-44-45.html)
Немира В. «Гении тоже страдают задержкой умственного развития», Utro.ru, № 162 (233), 2000 (http://www.autism.ru/read.asp?id=80&vol=0)
Gerald Weinberg, «Psychology of Computer Programming», Van Nostrand Reinhold, 1971
Tom DeMarco, «Timothy Lister, Peopleware : Productive Projects and Teams», Dorset House, 1987
Белая О. А. и др. «Психология программирования: человеко-машинный аспект информационных технологий», СПбГУ, 2004 (http://www.it-education.ru/reports/odintsov.htm)
Алистэр Коуберн, Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения, Humans and Technology, Октябрь, 1999
Кэтлин Мелимука, «Разговор с Томом де Марко», Computerworld, #05/1996
М. Ка де Ври, «Мистика лидерства. Развитие эмоционального интеллекта», Альпина паблишер, Москва, 2003.
И. Ашманов, "Правила Ашманова", 2002 (http://www.ashmanov.com/pap/)
Tom Peters, The Wow Project, Fast Company Magazine, Issue 24,May 1999
Joel Spolsky, "Command and Conquer and the Herd of Coconuts", March, 2000 ()
E. Yourdon, "Death March", The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects, Prentice Hall, 1997
B. W. Boehm, "Theory-W Software Project Management: Principles and Examples”, IEEE Transactions on Software Engineering, Vol. 15, No. 7, July 1989
Эд Салливан, "Время - деньги. Создание команды разработчиков программного обеспечения", Русская редакция, Москва, 2002.
Joel Spolsky, "The Guerrilla Guide to Interviewing", March, 2000 (http://www.joelonsoftware.com/articles/fog0000000073.html)
А. Коуберн, "Каждому проекту своя методология",Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод http://www.maxkir.com/sd/methyperproject_RUS.htm)
Питер Ф. Друкер, "Эффективный управляющий".
Моцарт и Сальери
Гуру программирования Ф. Брукс в 1975 году писал []: «Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов». Некоторые психологи, которые работают с программистами, идут дальше и даже утверждают, что программирование – это высшая форма творчества [].
Творчество - это интеллектуальная деятельность человека, законы которой нам неизвестны. Если бы мы знали законы творчества, то и картины, и стихи, и музыку, и программы уже давно бы создавали компьютеры. Творческое начало это то, что роднит программирование с наукой и искусством.
Творчество в программировании начинается с определения целей программы и заканчивается только тогда, когда в ее коде, написанном на каком-либо языке программирования, поставлена последняя точка. Попытки разделять программистов на творческую элиту, архитекторов и проектировщиков, и нетворческих программистов-кодеров не имеют под собой объективных оснований. Даже если алгоритм программы строго определен математически, два разных программиста его закодируют по-разному, и полученная программа будет иметь разные потребительские качества 4.
Факт 1. Программирование было, есть и останется в обозримом будущем творческой деятельностью.
Творчество неразрывно связано с вдохновением, а это субстанция капризная и непредсказуемая (помните знаменитый сон Д. И. Менделеева, про Периодическую таблицу элементов его имени?). Знаю только, что без вдохновения в программировании не обойтись. И чем сложнее задача, тем труднее извлечь это вдохновение из подсознания. Иногда для этого требуются часы, а иногда недели 5.
Программирование это не искусство, в том смысле, что оно не является творческим отражением и воспроизведением действительности в художественных образах. Об искусстве в программировании можно и должно говорить только в смысле умения, мастерства, знания дела, как и в любой другой профессии.
И как в любой другой профессии программистское мастерство может доставлять истинное эстетическое наслаждение, но только для людей, причастных к этой профессии 6.
Программирование это не наука. Наработки математиков в области логики, теории информации, численных методов, реляционной алгебры, теории графов и некоторых других дисциплинах на долю процента не покрывают сложность программистских задач. В программировании нет системы знаний о закономерностях создания программ. Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны - источники серьезных будущих проблем. Но не более того. Существующее состояние Software Engineering напоминает мне большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых у меня никогда в будущем не будет. Завтра в моей новой системе будут другие вычислительные машины, технологии, языки программирования, инструменты и окружающее ПО, новые проблемы взаимодействия с которыми мне обязательно придется решать.
Факт 2. Программирование - не искусство и не наука – это ремесло. Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.
А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского. Путь к мастерству в ремесле лежит только через опыт. Нельзя научиться программированию, читая книги. Как нельзя по книгам научиться писать романы, картины, стихи, музыку. А еще программистам нужен постоянный труд самоусовершенствования и саморазвития. Поэтому далеко не все, кто пишет программы, становятся профессионалами.
Факт 3. Производительность труда программистов с одинаковым уровнем знаний и опытом в обозримом будущем, по-прежнему, будет отличаться на порядок.
Более того, производительность одного и того же программиста в течение проекта будет так же отличаться на порядок даже при решении сходных по сложности задач.
Хотите, меряйте производительность в строках исходного кода, хотите – в функциональных точках.
Почему-то, если мы говорим о поэтах, художниках, композиторах, то разброс творческой производительности никого не удивляет. «Творческий полет», «творческий застой» - это про деятелей искусства. А когда говорим о неравномерности производительности программистов, то многие менеджеры начинают с этим спорить, и пытаются «пинать» программистов, как будто это заставит их думать быстрей. Не заставит. Но может заставить уйти или заняться имитацией работы.
Профессиональное творчество программиста принципиально отличается от творчества в науке и искусстве. Программистские задачи с каждым годом становятся все сложнее и объемнее, а сроки, за которые требуется решить эти задачи, наоборот, с каждым годом сокращаются. Поэтому современные программы создаются коллективами от нескольких до тысяч программистов, в то время как творческие деятели науки и искусства работают, как правило, в одиночку.
Правда существует еще прикладная наука, космонавтика, авиастроение, автомобилестроение и другие высокотехнологичные отрасли промышленности, в которых над созданием новых изделий трудятся сотни тысяч человек. Очень велик соблазн провести аналогию с этими отраслями и говорить об индустриальном подходе к разработке ПО. Не получается.
Упрощенно, путь от идеи до ее реализации в этих отраслях выглядит следующим образом: НИР-ОКР-завод. В верхней части этой пирамиды находятся отраслевые НИИ, которые производят идеи и занимаются проектированием новых изделий. На втором этаже пирамиды работают конструкторы в конструкторских бюро, в задачу которых входит реализация нового проекта в чертежах деталей и технологиях изготовления и сборки. На нижнем уровне находятся производственные мощности - заводы, на которых инженеры и рабочие воплощают «в железе» чертежи и технологии.
Если проводить аналогию, то программисты работают исключительно на вершине описанной пирамиды. Программирование – это проектирование и только проектирование. Роль конструкторского бюро для программного проекта выполняют компилятор и сборщик программ. А программистским аналогом завода, который переводит конструкторскую документацию в продукт, доступный потребителю, служит вычислительный комплекс, на котором выполняется созданная программа.
А теперь давайте вспомним, сколько НИР так и остались на бумаге, не дойдя до ОКР, и сколько еще ОКР закончилось закрытием тематики. Я думаю, что процент инноваций, дошедших до производства от общего числа проектов, выполненных в отраслевых НИИ, будет сравним с процентом успешных программных проектов. И давайте еще учтем, что ученые в НИИ опираются на достаточно хорошо изученные законы математики, физики и химии, а программирование, как мы отмечали выше, пока остается лишь ремесленным производством.
Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля. Я полагаю, что количество провальных проектов в этих областях ничуть не меньше, чем в программировании. Дай Бог, если хотя бы пятая часть кинофильмов не «ложится на полки» после первого показа.
И еще одна аналогия программных проектов с кинематографом. Наличие даже самых звездных актеров не обеспечивает успех фильма. Только талантливый режиссер способен организовать и вдохновить актеров на создание шедевра, открыть новые звезды. А талантливых режиссеров, как, впрочем, и талантливых менеджеров программных проектов, к сожалению, не так много, как хотелось бы.
Факт 4. В обозримом будущем большая часть проектов разработки ПО будет завершаться со срывами сроков и перерасходом бюджета, часть проектов не будет завершена вообще, и только приблизительно 20% проектов будут укладываться в первоначальный бюджет и сроки.
Бизнесмены должны помнить, что инвестиции в разработку ПО в обозримом будущем по-прежнему будут связаны с высокими рисками.
Но риски компенсируются тем, что прибыли от одного успешного проекта могут порой покрыть убытки от десятков менее удачных.
Есть еще нечто, что отличает труд профессионального программиста от ученого, художника, композитора и поэта. Предметом деятельности ученых являются упрощенные модели, в которых они могут абстрагироваться от большинства деталей реального мира, не существенных для их целей. Математик, доказывая новую теорему о тензорах, не заботится ни о чем, кроме системы постулатов, положенных в основание дифференциальной геометрии. Физик, описывая динамику жидкости в трубе, абстрагируется от того, как движутся и сталкиваются молекулы и от того, как движутся планеты вокруг Солнца. Деятели искусства тоже во многом оперируют абстракциями. Поэту, композитору, художнику достаточно лишь сделать намек, абрис объекта творчества, и на этом его работа закончена. Остальное пусть додумывает читатель, слушатель, зритель.
Программист тоже работает с абстракциями, но ему приходится держать в голове гораздо больше абстракций, чем любому ученому. Абстракции сопутствуют программисту на всех уровнях разработки программы от описания ее целей до исполняемого машинного кода. И этих уровней могут быть десятки. И на каждом уровне абстракций их деталей становится все больше и больше.
Дополнительно к абстрактному мышлению, программист должен обладать сильно выраженным системным мышлением, чтобы удерживать многочисленные взаимосвязи, существующие на всех уровнях программистских абстракций, а также взаимосвязи между этими уровнями. Еще одной сложностью является то, что все эти абстракции и взаимосвязи между ними изменяются во времени, и программист должен учитывать эту динамику.
Кроме того, программист должен обладать маниакальной усидчивостью, сосредоточенностью и упорством для перебора всех возможных вариантов поведения своих абстракций и доскональной проработки всех деталей. 7 Проработка должна быть абсолютно точной и не должна содержать ни одной ошибки, неправильного, лишнего или отсутствующего символа исходного кода (а это порой сотни тысяч строк).
Инструменты программирования: синтаксические анализаторы, компиляторы и проч., - лишь незначительно помогают в этой работе.
Еще одна особенность, которая присуща программистскому творчеству, это постоянное обновление информационных технологий 8, которые программисту необходимо знать и успешно применять в своей работе. Поэтому профессиональный программист должен, как сказал один из наших прежних вождей 9, «учиться, учиться и учиться». Программист должен удерживать в голове, постоянно пополнять и активно применять на практике гигабайты профессиональной информации. Это устройство компьютеров, компьютерных сетей и сетевые протоколы. Это операционные системы и языки программирования. Это программные интерфейсы промежуточного ПО и прикладных библиотек с особенностями и багами их реализации в конкретных продуктах. Это технологические стандарты, технологии разработки и инструменты, которые их поддерживают. Это архитектуры программных систем, паттерны и антипаттерны проектирования и много-много другой информации.
Еще в начале 70-х замечательный ученый академик А.П.Ершов сказал: “Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста”.
Образно можно сказать, что программист должен сочетать в себе легкость и полет таланта Моцарта с усидчивостью и скрупулезностью Сальери.
Описанные психологические особенности программистского творчества привели к тому, что наиболее успешными программистами становятся люди, которые обладают выраженным аутистическим складом мышления. Аутистическое мышление (от древнегр. autos — сам) — замкнуто-углубленный тип личности. Применительно к личности используется также термин «шизоид».
Факт 5. Аутист-шизоид – наиболее распространенный среди программистов тип личности.
Мы, программисты, все немного шизоиды 10.
По неофициальным данным [], в компании «Майкрософт» число аутистов среди сотрудников составляет от 5 до 20%. Аутизм это не болезнь! Мы просто не такие как остальное большинство, которое не готово сутками проводить время за мониторами компьютеров и получать от этого удовольствие. И, пожалуйста, не надо нас лечить и переделывать! Это удача для человечества, что рождаются аутисты. Так, по результатам исследований процент гениев (то есть людей, способности которых существенно выше средних) среди людей с диагнозом "аутизм" достигает 20%. В то время как среди так называемых "нормальных" людей он не превышает 0,001%. Психологи считают аутистами таких известных исторических личностей, как Ньютон, Эйнштейн, Гегель, Фрейд, Юнг, Агата Кристи и даже любимый Пушкин 11.
Аутизм сейчас популярная тема не только среди профессиональных психологов, но и в обществе. Про аутистов даже сняты художественные фильмы: «Человек дождя» и «Меркурий в опасности». Поэтому позволим себе отослать заинтересовавшегося читателя к многочисленным профессиональным и не очень источникам информации, которые в большом числе присутствуют в Интернете. Остановимся только на тех качествах шизоидного типа личности, на которые мы будем ссылаться в дальнейшем.
? Они ориентированы на свой внутренний мир, а не на окружающих их людей, они с трудом идут на установление контактов с другими людьми, их реакции часто необычны и непонятны окружающим, а привычки и пристрастия - устойчивы и с трудом поддаются изменению.
? Для них характерно сочетание противоречивых черт в личности и поведении: холодности и утонченной чувствительности, упрямства и податливости, настороженности и легковерия, апатичной бездеятельности и напористой целеустремленности, необщительности и неожиданной назойливости, застенчивости и бестактности, чрезмерных привязанностей и немотивированных антипатий, рациональных рассуждений и нелогичных поступков, богатства внутреннего мира и бесцветности его внешних проявлений.
? Они могут повторять одно и то же действие снова и снова.
Они хотят жить так, чтобы в окружающем их мире ничего не изменялось и чтобы события всегда происходили в привычном для них порядке. Даже незначительное изменение в этом порядке их очень расстраивает.
? На работе они часто неуправляемы, так как трудятся, исходя из собственных представлений о ценностях в жизни. Однако, в определенных областях, где требуется художественная экстравагантность, одаренность, нестандартность мышления, символизм, они могут достичь многого.
"Аутист видит в компьютере близкое существо, – считает Эми Клин, ассистент профессора Центра детского развития при Медицинской школе Йельского университета. – Компьютеры бескомпромиссны и негибки, а люди, с которыми нам приходится иметь дело, отличаются теми же качествами". Аутизм ограничивает способность таких людей к общению, но вознаграждает их даром невероятной концентрации и творческой продуктивности [].
Аутистическая природа программирования это не просто еще один факт, а, по-видимому, самый важный из всех фактов, которые необходимо учитывать, если мы хотим успешно производить программное обеспечение.
Каждый программный проект это потенциальная катастрофа. И если мы не будем постоянно прилагать усилия к тому, чтобы этой катастрофы избежать, мы неотвратимо к ней придем. Мы подробно писали о специфической сложности программных проектов и непредсказуемости их главной составляющей – программистов. Что же позволяет нам при разработке ПО с уверенностью смотреть в завтрашний день? Ответ прост – управление на макро уровне. В статистической динамике газа мы абстрагируемся от броуновского движения каждой из молекул и оперируем усредненными характеристиками: скорость потока, температура, давление. Аналогично, в программном проекте мы можем в разы ошибиться при оценке трудоемкости реализации каждого отдельного функционального требования. Но наши ошибки будут как в меньшую, так и в большую сторону. Поэтому для проекта в целом они будут компенсироваться 12. В моей практике ошибка суммарной трудоемкости проекта составляет не более 30%.
Производительность участников проекта также может отличаться в разы, но средняя производительность по всем участникам вещь достаточно стабильная и прогнозируемая. По моему опыту оптимальное с точки зрения макроуправления количество человек в группе разработчиков – 4-6. Если проект большой, то необходимо провести его архитектурную декомпозицию на минимально связанные подсистемы, разработку которых следует вести отдельными группами со своими руководителями и планами.
Задачей любого управления является достижение некоторой цели. В нашем случае целью управления является успешное завершение проекта. Если кто-то думает, что успех проекта это реализация в программе 100% требований к назначенному сроку и в пределах выделенного бюджета, то это не так. Успех проекта живет в головах людей. Успех это в первую очередь чувство удовлетворения заказчика 13. Но не только. Успех это еще и чувство удовлетворения людей, которые выполняли проект. Вряд ли стоит называть проект успешным, даже если заказчик остался доволен его результатами, но при этом из компании ушли все профессионалы, участвовавшие в этом проекте. Я сознательно не касаюсь здесь вопросов экономической эффективности проекта и не потому, что «джентльмены о деньгах не говорят», а потому, что это самостоятельный и непростой вопрос совсем из другой области.
Факт 6. Цель управления программным проектом лежит в области психологии.
В каждом программном проекте десятки процессов: бизнес-анализ, планирование, проектирование, кодирование, конфигурирование, документирование, тестирование, внедрение, сопровождение и много чего еще. Эти процессы могут быть определены, документированы и даже нормированы, а могут быть, и нет. Но менеджер проекта не управляет процессами, он управляет лишь людьми, которые эти процессы выполняют. А управлять людьми можно только, ставя им правильные цели и мотивируя людей на их достижение. А оценка и мотивация людей - это опять в чистом виде психология.
Факт 7. Средства управления программным проектом лежат в области психологии.
То, что важным фактором программистского проекта является психология, начали писать более 30 лет назад, книги Венберга [] и Де Марко [] ничуть не утратили своей актуальности и сегодня. Но понимание того, что психология является решающим фактором успеха или неуспеха проектов разработки ПО, пришло только в последние годы. Радикальным решением проблем кризиса программирования поочередно объявлялись поиск лучшего языка программирования (1960-е годы), технологии программирования (1970-е годы), инструментария программирования (1980-е годы), системы качества (1990-е). И только центральному и ключевому фактору - фигуре самого программиста - внимание почти не уделялось [].
«Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте». Это вывод Алистэра Коуберна [], который базируется на результатах анализа очень разных программных проектов, реализованных за последние 20 лет. Проекты отличались друг от друга по количеству программистов, по срокам выполнения, по применяемой технологии - от самой тяжелой (CMM 5-го уровня) до полного ее отсутствия. Коуберн не обнаружил статистически значимой корреляции успеха или неуспеха проекта ни с одной из перечисленных характеристик.
Не правы те, кто утверждает, что нет разницы между управлением программными проектами и проектами в любой другой отрасли промышленности, например, в строительстве или авиастроении. Разница есть и она принципиальная.
Факт 8. Основная сложность управления программными проектами заключается в противоречии между коллективным характером труда и аутистической природой программирования.
О чем и зачем
Почему эссе? Потому, что этот материал на достаточно частную тему – психологические аспекты управления программными проектами. Потому, что трактовка рассмотренных вопросов отражает субъективный опыт автора и не претендует на полноту.
Для чего написана эта статья? Для того чтобы обнародовать еще одну попытку ответить на традиционные для России вопросы: «кто виноват?» и «что делать?». Вдруг кто-нибудь еще не знает правильных ответов? 1
Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» [] пришла к следующим неутешительным выводам.
«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%»?
Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?
Начну сразу с ответов.
Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».
Что делать? Управлять людьми. Успех, а равно и провал, проектов по производству ПО на 100% лежит в области психологии.
Все, что написано далее, посвящено не тому, чтобы доказать или обосновать приведенные выше выводы (автор осознает непосильность для себя подобной задачи), а тому, чтобы поделиться с заинтересовавшимся читателем теми жизненными наблюдениями, которые, в конце концов, привели к данным выводам.
Впрочем, совсем уж субъективные иллюстрации из личного опыта, которые, на мой взгляд, могут быть опущены без ущерба для понимания остального содержания статьи, выделены мелким шрифтом и оформлены в виде сносок.
Как должно солидным людям, давайте договоримся о понятиях. Поскольку была выбрана форма эссе, а не академической монографии, то автор может позволить себе вольность и дать свои определения терминов, которыми нам предстоит оперировать, не приводя многочисленное цитирование первоисточников и углубленный анализ различных трактовок понятий. 2 Разумеется, это не мои определения, а то, что сложилось и укрепилось в голове под влиянием многих авторов за годы программирования.
Программирование - процесс отображения определенного множества целей на множество машинных команд и данных, интерпретация которых хотя бы на одном компьютере обеспечивает достижение поставленных целей.
Цели могут быть любые: воспроизведение звука в динамике ПК, расчет траектории полета космического аппарата на Марс, печать годового балансового отчета и т.д. Важно то, что они должны быть определены. Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели 3.
Это отображение может быть очень простым, например, перфорирование машинных команд и данных на перфокартах. А может быть многоступенчатым и очень сложным, когда сначала цели отображаются на требования к системе, требования – на высокоуровневую архитектуру и спецификации компонентов, спецификации - на дизайн компонентов, дизайн - на исходный код. Далее исходный код при помощи компиляторов и сборщиков отображается на код развертывания, код развертывания – на вызовы функций ПО окружения (ОС, промежуточное ПО, базы данных), которое может располагаться на множестве компьютеров, объединенных в сеть, и только после этого – в машинные команды и данные.
Профессиональное программирование (синоним производство программ) – деятельность, направленная на получение доходов при помощи программирования.
Принципиальным отличием от просто программирования является то, что имеется или, по крайней мере, предполагается некоторый потребитель, который готов платить за использование результатов программирования. Отсюда следует важный вывод о том, что производство программ это всегда коллективная деятельность, в которой участвуют минимум два человека: программист и потребитель.
Профессиональный программист – человек, который занимается профессиональным программированием. Профессионального программиста следует отличать от профессионала (мастера в программировании). Разброс профессионального мастерства в программировании достаточно широк и далеко не каждый, кто зарабатывает на жизнь программированием, является мастером, но об этом позже.
Обозримое будущее – ближайшие 5-10 лет, на которые автор готов экстраполировать действие закономерностей и выводов, изложенных в статье. Возможно, что за это время удастся осуществить прорывы или в искусственном интеллекте, или в теории доказательства правильности программ, которые могут революционно изменить состояние дел в программировании.
Резюме. Растите профессионалов
Работа менеджера проекта подобна труду садовника.
Подобно тому, как садовник любовно отбирает наиболее подходящие растения для своего будущего сада, менеджер набирает людей, наиболее соответствующих целям проекта.
Подобно тому, как садовник ищет лучшую почву для каждого растения с учетом его особенностей, менеджер для каждого участника проектной команды ищет наиболее подходящую для него задачу.
Подобно тому, как садовник тщательно лелеет своих питомцев, оберегает их от вредных воздействий, следит за тем, чтобы ни одно растение не затеняло другое, а только дополняло его и способствовало его росту, менеджер проекта терпеливо работает с каждым участником проектной команды, способствуя его правильному развитию, охраняя от внешних и внутренних потрясений, для того, чтобы максимально раскрыть его индивидуальные способности и увеличить отдачу от них, с удовлетворением отмечает каждое новое достижение.
«Что посеешь, то и пожнешь» - этот закон одинаково применим как к труду садовода, так и к труду менеджера проекта. Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложите в людей часть своей души, и вам воздастся сторицей.
Управляем катастрофой
До сих пор мы только констатировали объективно существующие трудности и проблемы, которые связаны с разработкой программных проектов. Читатель давно уже в праве ожидать от нас ответа на вопрос «что делать?». Короткий ответ – управлять людьми, которые вовлечены в проект. И круг таких людей достаточно широк. Оставшаяся часть статьи будет посвящена управлению программными проектами, а если точнее, то работе менеджера проекта 14 по управлению людьми, как внутри проекта, так и вне него. Начнем по порядку.
Над входом в храм Аполлона в Дельфах написано «Познай себя». Начинайте проект с себя. Вы – менеджер проекта. Если это ваш первый проект, то поздравляю вас с приобщением к благородной профессии. «Управление благородно по своей сути. Менеджмент ничего не имеет общего с деятельностью бюрократа, сидящего наверху. Менеджер делает самую необходимую в компании работу. Благодаря нему становится возможным выполнение самых грандиозных проектов. Нет более почетной работы, чем та, которую делает настоящий менеджер» [].
Но даже, если у вас сверхвысокий IQ , это не поможет вам в управлении людьми. Чтобы управлять людьми, нужны совсем другие качества. Менеджер должен обладать сверхвысоким EQ – коэффициентом эмоционального интеллекта ( Emotional Intelligence ). Вот три компонента эмоционального интеллекта:
? Понять свои собственные чувства.
? Научиться управлять ими.
? Научиться распознавать эмоции других и управлять ими.
Загляните в себя, есть ли у вас необходимые качества. В силу аутистической природы программирования хороший программист, как правило, этими качествами не обладает. Из хороших программистов выходят, как правило, плохие менеджеры проектов. Аутисты предпочитают не общаться с другими людьми и не испытывать потребности в таком общении, они не интересуются другими людьми, стремятся быть в одиночестве. Недостаточный EQ и шизоидные наклонности могут привести к параноидальному стилю управления: чрезмерной бдительности, подозрительности, озабоченности скрытыми мотивами, повышенной тревожности [].
Такие руководители считают подчиненных некомпетентными симулянтами, которые не любят свою работу и стремятся избежать ее, если у них есть такая возможность. Руководители подобного типа практикуют строгий контроль через активное личное наблюдение, формальные правила и ограничения. Ведут себя агрессивно, в особенности с теми подчиненными, которые высказывают свое мнение. «Кнут и пряник»15
для них единственные инструменты мотивации подчиненных. Эти инструменты, может быть, полезны, когда мы управляем стадом баранов, но для управления командой эйнштейнов категорически не годятся. Эйнштейны очень быстро разбегаются, если, конечно, их не огородить колючей проволокой 16. Мы еще вернемся к вопросу мотивации эйнштейнов.
Если у вас недостаточный EQ , не отчаивайтесь. В отличие от IQ , который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни.
Призыв 1. Повышайте свой эмоциональный интеллект, если вы хотите руководить успешными программными проектами.
Поймите свои собственные мотивы. Ответьте себе на вопрос, почему вы беретесь именно за этот проект 17. Помните, что вам предстоит поставить на кон свою репутацию и вложить в проект душу. «Вполнакала проекты не делаются» - очень точная формулировка И. Ставинского []. Поэтому нужно четко понимать, в чем будет ваш выигрыш в случае успешного завершения проекта.
Призыв 2. Поймите свои личные цели, достижение которых связано с успешным завершением проекта.
Эти цели не обязательно должны быть материальными: повышение оклада или должности. Это могут быть идеальные цели: познать новое, сделать то, что до вас никто не делал, обеспечить существенные конкурентные преимущества вашей компании или, наконец, осчастливить все человечество. Главное, чтобы для вас лично эта цель была значимой настолько, чтобы стремление к ее достижению могло бы поддерживать в вас состояние постоянного горения от начала до завершения проекта.
Как мы отмечали ранее, главная цель управления проектом - вызвать у заказчика чувство удовлетворения.
Степень удовлетворенности – субъективная величина, которая является отношением субъективной оценки достижений к субъективной же оценке ожиданий или потребностей. Отсюда следует:
Призыв 3. Продавайте свой проект от начала до завершения работ.
Понимание этого правила пришло ко мне достаточно давно 18, но формулировку его я заимствовал у Тома Питерса []. Продавать проект следует в первую очередь заказчику. Если, после заключения договора на разработку ПО, вы планируете следующую встречу с заказчиком на приемо-сдаточных испытаниях, то вы прямой дорогой идете к катастрофе. Вы должны работать над тем, чтобы заказчик постоянно испытывал чувство удовлетворения от начала проекта до его завершения. Этого можно добиться, если вы разрабатываете проект итерационно: чуть-чуть спроектировали, чуть-чуть закодировали, чуть-чуть протестировали и продали этот результат заказчику. Продали - это означает - убедили (снова психология) заказчика, что вы представили ему нечто большее, чем то, на что он мог бы рассчитывать на текущем этапе проекта. Если во время приемо-сдаточных испытаний критика заказчиком того, что вы произвели, это, скорее всего, признак неизбежной катастрофы, то замечания на ранних итерациях это весомое свидетельство движения вашего проекта к успеху. С радостью принимайте их и тщательно анализируйте 19. Даже если вы не будете уверены в их положительном влиянии (вы ведь можете что-то не знать о бизнесе заказчика), оперативно совершенствуйте свой проект и вновь представляйте результаты заказчику. Тем самым заказчик становится соучастником вашего проекта и соавтором будущего результата. А какой же родитель не любит ребенка, которого он сам растил и воспитывал. Это обратная связь, которая необходима любой системе управления, если вы хотите, чтобы она обладала устойчивостью. Это гарантия того, что на приемо-сдаточных испытаниях заказчик будет ожидать ровно то, что вы ему представите. Управляйте ожиданиями заказчика и формируйте у него адекватную оценку представленного вами результата.
Заказчик далеко не единственный человек, которому вы должны постоянно продавать свой проект. Заказчика окружают люди, которые могут существенно влиять на формирование его мнения. Например, будущие пользователи вашей программы. Вы просто обязаны продавать ваш проект и им. Так же полезно продать проект экспертам в той области ИТ, к которой относится ваш проект. Заручитесь их поддержкой, она особенно пригодится вам, если заказчик не является специалистом в ИТ.
Очень важно продавать проект вашему руководству, если заказчик проекта со стороны. Руководство должно быть постоянно уверено, что проект завершится в срок и в полном объеме. Сделайте проект прозрачным, пусть руководство видит все, от плана проекта до исходного кода программ и скриптов. Руководство, конечно, не поймет, как продвигается ваш проект, но избавится от присущей ему фобии, что от него что-то скрывают. Разработайте для руководства небольшой и ясный набор индикаторов (об индикаторах проекта чуть позже), который будет отражать продвижение проекта к цели, и регулярно представляйте отчет по их изменению, чтобы руководство могло следить за прогрессом проекта.
И если уж речь зашла о руководстве, то уместно привести здесь еще одно правило.
Призыв 4. Не позволяйте руководству принимать других решений в вашем проекте, кроме двух: остановить проект или сменить менеджера.
По всем остальным вопросам в проекте принимать решения должен менеджер, а руководство вправе лишь высказывать свои рекомендации. Если это не так, то вы идете к катастрофе. Джоель Спольски [] так описывает последствия вмешательства руководства: «…Руководители разных уровней с удовольствием запускали руки в каждый стряпающийся пирог, раздавая указания направо и налево в стиле, который я стал называть порулил и убегай. «Порулил и убегай» потому, что начальники появлялись на горизонте вероломно, отдавали глупые распоряжения как именно все, черт побери, должно быть сделано, без какого-либо предварительного размышления, и покидали комнату, оставляя всех собирать осколки».
Если вам не удалось оградить проект от подобных вмешательств, вам, скорее всего, придется собирать осколки до его завершения.
А теперь о самом главном в управлении программным проектом – управлении проектной командой. Управлять людьми – значит побуждать их к правильным действиям. А побуждать их можно, только управляя мотивами. Согласно теории мотивации для того, чтобы человек совершил какое либо действие он должен испытывать некую потребность и предполагать, что, выполнив это действие, он в той или иной степени эту потребность удовлетворит. Поэтому управление мотивами осуществляется, как правило, в двух направлениях: 1) формирование правильных потребностей; 2) формирование правильной оценки степени их удовлетворения 20.
Я отношу себя к сторонникам гуманистического направления в теориях мотивации и исхожу в своей практической деятельности из структуры потребностей, которую описывает пирамида А. Маслоу. Мои многолетние наблюдения показывают, что потребности нижнего уровня пирамиды (физиологические и безопасности) для программистов, как, впрочем, и для других работников интеллектуального труда, играют несущественную роль. Это означает, что если эти потребности удовлетворены процентов на 50-70, то их дальнейшее удовлетворение слабо мотивирует работу программиста. Для программистов гораздо большее значение имеет удовлетворение потребностей принадлежности, самоуважения и самоактуализации. Причем, чем выше квалификация программиста, тем на более высоком уровне пирамиды Маслоу находятся мотивирующие его потребности. Попробуйте уговорить суперпрограммиста перейти на техническое сопровождение системы, даже если вы пообещаете ему в два раза большую зарплату. А вот уговорить его перейти на проект в области сверхновых технологий вполне возможно, даже при некоторой потере в доходах.
Об этом же пишет Э. Йордан []: «Деньги, выгода, комфорт и тому подобное являются факторами «гигиены» - их отсутствие вызывает неудовлетворенность, однако они не могут заставить людей полюбить свою работу и дать им необходимые внутренние стимулы.
Что действительно может дать такие стимулы, так это ощущение значительности достигнутых результатов, гордость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост - все то, что обогащает работу». Об этом же более 30-ти лет назад писал Вейнберг []: «Творчески работающему программисту присуща глубокая внутренняя мотивация». На мой взгляд, это еще одно следствие аутистической природы программирования.
Призыв 5. Имейте ясное представление о мотивах каждого участника проекта, чтобы эффективно управлять проектной командой.
Как я уже отмечал ранее, потребности каждого программиста зависят от его возраста, опыта и квалификации. Позволю себе привести свою экспертную оценку распределения мотивирующих потребностей для профессиональных программистов.
Потребности |
Профессионализм |
||
Начинающий |
Опытный |
Профессионал |
|
Материальные (зарплата, условия труда, социальный пакет и проч.) |
50% |
20% |
|
Безопасности (стабильность компании, востребованность технологии проекта на рынке труда, возможность повысить квалификацию) |
20% |
||
Принадлежности (возможность учиться у более опытных коллег, опыт участия в успешном проекте, признание в коллективе) |
40% |
20% |
10% |
Самоуважения (развиваться, делать что-либо лучше других, повышение в должности, самостоятельность и ответственность в работе) |
10% |
30% |
40% |
Самоактуализации (амбициозность целей проекта – сделать то, что никто не делал или не смог сделать) |
10% |
50% |
|
Команда успешного проекта это команда победителей. Успешный проект должен сделать победителем всех его участников [].
Призыв 6. Рассматривайте работу команды над проектом как корпоративную игру, в которой каждый участник, стремится к достижению своих личных целей, продвигая проект к успеху.
Управление командой начинается с ее формирования.
Призыв 7. При наборе персонала убедитесь, что человек сможет сделать то, что нужно в вашем проекте и хочет то, что вы сможете ему дать.
Вроде все просто, однако, это не так. Сможет это не только знает и умеет, но еще и захочет 21. А часто бывает ситуация, что не знает и не умеет, например, если технология совершенно новая, но хочет. И этого стремления, как правило, бывает достаточно, чтобы освоить новую технологию и успешно решить поставленную задачу. Главный вывод, который отсюда следует это то, что на серьезный проект, надо набирать разных программистов. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его квалификацию и найдете достойную задачу, которая его заинтересует.
В настоящее время нет каких-либо формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием 22. При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволит вам создать эффективную программистскую команду. О практике проведения интервью могу рекомендовать работы [, ], в которых изложены подходы, во многом совпадающие с моим опытом.
Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации.
Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса - кустарным творением программистов - когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает
для пользователя.
Призыв 8. Не загружайте программистов несвойственной для них работой. Включайте в проектную команду, бизнес-аналитиков, эргономистов, художников-дизайнеров, документалистов. Разделение труда - залог перехода от кустарного производства к более эффективному промышленному производству.
Теперь, когда цели определены, команда собрана, пора приступать непосредственно к созданию программной системы. Поскольку, разработка ПО, как мы отмечали выше, корпоративная игра, то первое, что мы должны сделать, это договориться о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды в проекте. Повторим вслед за автором []: «Каждому проекту своя технология». И чем больше и ответственней проект тем «тяжелей» должна быть технология. Технология может меняться вместе с развитием и ростом проекта, но на каждом этапе она должна быть определена и описана . Бессмысленно спрашивать с программиста ответа за то, что ему не поручено 23.
Призыв 9. Договоритесь о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды.
Регламенты и стандарты требуются еще и для того, чтобы все участники проекта разговаривали на одном языке, а ваш проект не превратился в проект строительства Вавилонской башни.
Иначе, например, если не определено или не исполняется соглашение по правилам кодирования, программисты быстро перестанут понимать друг друга.
Главная задача менеджера - обеспечить максимально эффективное использование знаний и способностей каждого участника проекта для решения проектных задач. Набранная вами группа специалистов это еще далеко не та команда, которая способна быстро и качественно достигать поставленные цели, умеющая самостоятельно принимать нестандартные и эффективные решения. В силу аутистической природы программирования набранная вами группа это собрание индивидуалистов-эйнштейнов, которые, как правило, самодостаточны и не нуждаются ни в руководстве, ни в общении. Для того, чтобы из группы получилась команда, необходима общность представлений участников о нормах поведения в коллективе и ожиданиях от каждого из его участников. Каждый участник команды должен понимать, какое трудовое поведение приемлемо, а какое порицается, каковы должны быть отношения в группе, стиль и методы работы. У меня выработалось определенное представление о правильных нормах поведения, которые я настойчиво внедряю в своих проектах. На мой взгляд, программист может считать себя профессионалом только тогда, когда:
Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги.
Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению.
Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело.
Постоянно приобретет новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег.
Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет компромиссы при противоречиях.
Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.
Основные усилия по мотивации участников проектной команды я направляю на то чтобы стимулировать правильное поведение.
Призыв 10. Постоянно работайте над строительством команды, мотивируйте правильное поведение участников проекта.
Очень важно, чтобы каждый член проектной команды знал, или хотя бы имел при желании возможность узнать о проекте не меньше, чем его менеджер. И не стоит ничего скрывать, ни проблем с заказчиком, ни разногласий с руководством. Трудно ожидать самостоятельные, нестандартные и эффективные решения от человека, у которого «шорами» ограничено видение проблемы.
Ошибкой являются попытки управления проектом на микро-уровне: мотивирование достижения формальных индивидуальных показателей, например, реализация программистом функциональных требований, количество написанных им строк исходного кода или плотность выявленных ошибок. В творческой деятельности формальные подходы не работают 24. Де Марко [] по поводу одной из своих коллег говорил: «я слабо представляю, какой вклад она вносит в мой проект, но за 12 лет ее работы в компании все проекты, в которых она участвовала, заканчивались успехом». За ответом направляю к его книге.
Основным инструментом управления у менеджера является план работ. Как мы уже отмечали ранее, работа по проекту должна вестись итерационно, а каждая итерация должна наращивать функциональность, которая определена требованиями к системе. Наиболее приемлемое время итерации от 2 до 6 недель. Именно на этот срок должно осуществляться детальное планирование. Поскольку в реализацию попадают только хорошо проработанные системные требования, то можно добиться достаточно высокой точности плана. Трудоемкость элементарных работ детального плана должна составлять от 4 до 20 часов при расчете на среднего программиста. Каждая итерация должна заканчиваться коллективным анализом «Lessons Learned»: удалось ли достичь поставленных целей, какие проблемы пришлось решать, как реорганизовать технологические процессы для более эффективной работы, - и детальным планированием следующей итерации.
Макро-показателей, по которым менеджер должен осуществлять мониторинг проекта, не так уж и много:
? Процент реализованных функциональных требований от общего числа.
? Объем затраченных на разработку человеко-часов.
? Количество строк исходного кода.
? Количество ошибок выявленных и закрытых.
Динамика этих показателей в сравнении с плановыми значениями позволяет вам и вашему руководству формально судить об успешности продвижения проекта. Если эти показатели существенно (более, чем на 10-15%) отличаются от прогнозируемых, то это свидетельствует о возможных проблемах проекта. Например, если количество кода превышает ожидания, то это может быть следствием ошибок в оценке трудоемкости (придется пересматривать планы, поскольку, скорее всего, увеличится срок проекта) или недостатков архитектуры и слабого повторного использования кода. Меньшее по сравнению с ожиданиями количество выявленных ошибок может свидетельствовать о недостатках в тестировании.
Программисты это, как правило, очень трудолюбивые люди (порой до фанатизма), с глубокой внутренней мотивацией к программистской работе. Как правило, я не вмешиваюсь в работу конкретного программиста, если срок выполнения поставленной задачи не превышен в 2-3 раза по сравнению с оценками в детальном плане. Так я определил для себя допуск на разброс траекторий на молекулярном уровне. Это оправдано, поскольку некоторые задачи решаются в разы быстрее, и на макро-уровне проект продвигается в соответствии с планом. Но если на микро- уровне возникают существенные отклонения от плана, это служит поводом для анализа причин неэффективной работы программиста.
Для эффективной работы программисту необходимо и достаточно выполнение четырех условий:
? Понимание целей работы.
? Желание ее сделать.
? Умение ее делать.
? Возможность ее сделать.
Неадекватное понимание целей конкретного проекта может привести к проблемам. Большинству опытных программистов свойственно стремление решить свою задачу не просто хорошо, а как можно лучше.
Они стремятся сделать задачу для самого общего случая, оптимально по памяти и быстродействию, используя самые последние достижения информационных технологий, закладывая в архитектуру возможность дальнейших расширений. Доводя свою программу до совершенства, программист способен затратить гораздо больше времени, чем реально требуется на задачу. Это стремление всегда вступает в конфликт с коммерческой стороной профессионального программирования, как способа получения доходов. С точки зрения заказчика, качественная программа это та, которая удовлетворяет заявленным требованиям. Не более того 25.
Призыв 11. Нацеливайте программистов на правильное решение задачи максимально быстрым способом.
Опыт свидетельствует, что более чем в 90% случаев ее не придется переделывать. Если работа вашей подпрограммы занимает только 1% общего времени выполнения, то, затратив сколько угодно времени на оптимизацию ее алгоритма, вы не добьетесь улучшения системных характеристик более чем на 1%. Такой выигрыш вряд ли стоит того, чтобы тратить время на оптимизацию. Со всеми остальными программистским наворотами дело обычно обстоит так же.
О мотивации программистов я уже говорил, поэтому добавлю лишь одно правило.
Призыв 12. Не пытайтесь получить от программиста больше того, что он хочет вам дать.
Ключевое слово здесь «хочет», заметьте, не «может», а именно «хочет» 26. Задача не будет выполнена за любое отведенное на нее время, если у программиста нет мотивов для ее решения. Или сумейте мотивировать программиста на выполнение задания, или передайте ее другому участнику проекта. Другого пути нет.
Еще раз напомню, что доминирующие потребности программистов находятся в верхней части пирамиды Маслоу, поэтому пинать и пугать их - занятие совершенно бесперспективное. Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег. Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности).
Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм. Сложнее дело обстоит с суперпрограммистами. Их основным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте – системная архитектура и реализация архитектурно значимых компонентов системы (скелета системы). При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить любую задачу в проекте.
Третье условие эффективной работы программиста – умение делать порученную работу. Как правило, начинающие программисты мало что умеют. Их главный метод программирования – копирование чужих образцов (Copy/Paste). Это естественный путь обучения ремеслу. Вспомним художников, которые учатся, копируя полотна великих мастеров. Важно, чтобы образцы для подражания были достойными. Поэтому целесообразно поручать задачу паре программистов, в которой один из них выступает наставником, а другой подмастерьем, перенимающим опыт.
У меня нет личного опыта парного программирования, которое рекомендует xProgramming, когда одну программу пишут по очереди. Но есть накопленная с годами уверенность, что ревизия кода более опытным коллегой на предмет «изобретения велосипеда» просто необходима. Кстати «изобретение велосипеда» любимое занятие не только среди начинающих, но и среди уже достаточно опытных программистов, у которых всегда возникает потребность переписать все по-своему.
Этому, как правило, есть две причины. Первая - недооценка сложности поставленной задачи. Вторая - недостаток времени для изучения достижений технологий, используемых в проекте.
Дополнительно, парная ответственность за исходный код страхует ваш проект от негативных последствий неожиданного ухода одного из специалистов 27.
Призыв 13. Планируйте время на самообучение участников проектной команды и обучение менее опытных программистов более опытными наставниками.
Время на это все равно тратится. Но если времени на обучения не достаточно, то будьте готовы к тому, что бездумное применение технологии Copy/Paste будет приводить к размножению ошибок в вашем проекте в геометрической прогрессии, и что масса времени будет тратиться на изобретение очередного велосипеда. Все это неизбежно приведет к снижению общей эффективности работ по проекту.
И о последнем условии эффективной работы – программисту должна быть предоставлена возможность сделать порученную работу. Здесь речь идет не о тривиальном наличии компьютера и инструментов разработки 28. И не о наличие отдельного кабинета, о котором пишет Де Марко 29. В творческой деятельности обязательным элементом ответственности является свобода выбора пути решения стоящей проблемы. Свобода не только необходимое условие творчества, но и важный мотивирующий фактор. Даже если вы уверены в существовании более правильного решения, вы не в праве настаивать на нем, вы можете высказать свое мнение только в виде рекомендации. Предоставьте членам проектной команды право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет. Впрочем, вы ведь тоже можете ошибаться.
Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов свободы. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники.
Работать больше, это совсем не значит - работать продуктивнее. Скорее наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переработкам. «Хорошо управляемое предприятие - это спокойное место. Зато «фабрика, отличающаяся "кипучей" деятельностью и "трудовым героизмом" работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе» [].
Если программист адекватно мотивирован для того, чтобы выполнить порученную работу, то он будет стремиться сделать ее максимально быстро и с необходимым качеством. Многие программисты, особенно молодые, по собственной инициативе готовы тратить на решение задачи по 12-16 часов в сутки. Это неправильно, эффективность работы резко снижается, и при злоупотреблении сверхурочной работой программист уподобляется мухе, бьющейся головой о стекло, вместо того чтобы методично искать правильное решение 30.
Еще одно распространенное заблуждение менеджеров: оптимизм программистов. Я не имею в виду начинающих программистов, я говорю об опытных. На мой взгляд, заниженные оценки сроков решения поставленной задачи, как правило, являются следствием морального давления менеджеров. Программисту в силу своего аутистического нежелания общаться с другими людьми, легче согласиться с навязываемыми руководством сроками, чем объяснять начальству, почему оно не право.
Отношение менеджера и членов успешной проектной команды должны строится не на принципах подчинения, а на принципах партнерства. Партнерство не может быть без доверия. Если в проектной команде нет доверия, это путь к катастрофе.
Призыв 14. Не мешайте программистам. Доверяйте им. Обеспечивайте им свободу творчества. Предоставляйте им право на ошибку. Не оказывайте на них давление.
Повторюсь, управляйте проектом на макро-уровне. Не бойтесь, если одна молекула временно летит медленнее, чем остальные, или не совсем в ту сторону. Главное, чтобы это не было системой, чтобы среднее движение всех молекул было направлено к цели и осуществлялось с необходимой скоростью.
Важнейшим неформальным макро- показателем состояния проекта являются коммуникации, их качество и количество. Если угодно, то по моей экспертной оценке коммуникации, включая наставничество и консультации, в успешном проекте занимают 30-50% рабочего времени. Только благодаря эффективным коммуникациям можно достигнуть синергетического эффекта, который отличает команду от просто группы. Мне неоднократно приходилось убеждаться, что освоение новой информационной технологии парой программистов, которые осуществляют интенсивный обмен знаниями, происходит минимум в 3 раза быстрее, чем в случае, когда ту же работу выполняет один программист. Недостаточное количество коммуникаций свидетельствует, как правило, об отсутствии команды, каждый углублен в свою задачу и не интересуется, что делают его коллеги. В результате будет сделано не то, что нужно, а то, что будет сделано, вряд ли удастся интегрировать в единую систему. Если через день после получения недельного задания у программиста не возникло уточняющих вопросов, жди беды. Скорее всего, он с головой ушел в «проектирование дома, забыв уточнить, для чего он предназначен» []. Учитывая шизоидную несклонность программистов к общению, менеджеру требуется прилагать значительные усилия для того, чтобы мотивировать необходимый уровень коммуникаций.
Эффективность коммуникаций напрямую связана с доброжелательностью межличностных отношений. Не стоит ожидать плодотворного обмена информацией, если участники проекта поставлены в условия конкуренции или разделены барьерами должностной иерархии. Доброжелательность это не отсутствие споров и дискуссий, а нацеленность в спорах и дискуссиях на поиск консенсуса (интегрированного решения проблемы, которое объединяет лучшие стороны всех предложений), а не на выяснение межличностных отношений.
Меня давно перестали напрягать обсуждения в рабочее время членами проектной команды вопросов, не связанных непосредственно с проектом. Я рассматриваю их как способ установления открытых и доверительных отношений между коллегами, без которых немыслимы эффективные коммуникации по производственным вопросам.
Кроме того, это способ отвлечься от зацикленности, от длительных и безуспешных попыток решить задачу, способ вытеснить проблему в подсознание. Все, кто занимался творческой деятельностью, понимают необходимость данной фазы в интеллектуальном процессе. В психологии это называют фазой инкубации проблемы.
Для успешного проекта характерно постоянное ощущение его участниками чувства удовлетворения и гордости за результаты своей работы, чувства оптимизма. Только наблюдая и анализируя общение участников проектной команды, можно получить информацию об их удовлетворенности состоянием дел. Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников.
Призыв 15. Наблюдайте за коммуникациями в проекте. Постоянно поддерживайте необходимый уровень энтузиазма в проекте. Мотивируйте участников проекта на установление эффективного неформального общения.
Объективности ради отметим, что слишком интенсивные коммуникации могут свидетельствовать о проблемах в проекте. Например, о слишком большой связанности архитектурных компонентов, разрабатываемых разными людьми. Это так же может свидетельствовать о недостатках нормативной или проектной документации, в которых отсутствуют ответы на повседневные рабочие вопросы, и их приходится искать, отвлекая коллег. Хотя, в силу аутистической природы программистов избыток коммуникаций в проекте встречается достаточно редко.
З.Ы.
Я ничего не сказал о том, что для успеха проекта надо еще составлять календарный план, управлять рисками, требованиями, конфигурацией, качеством, проектировать архитектуру, соблюдать стандарты кодирования, тестировать и документировать систему и много чего еще. Но, во-первых, вы все это давно уже знаете. Во-вторых, наличие детальных диаграмм Ганта пока еще не спасло от катастрофы ни один проект. И, наконец, в-третьих, «разруха не в клозетах, разруха в головах», как говорил профессор Преображенский.
Аннотация.
Рассматривается задача семантически корректной и функционально содержательной реконсиляции прикладных данных. Задача имеет ключевое значение для успешного применения современных технологий оптимистической репликации и создания перспективных распределенных приложений, таких как системы коллективной инженерии, мобильные базы данных, семантические сети. Рассматривается модельно-ориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL. На основе статического анализа формальных спецификаций прикладной модели выявляются отношения зависимости и отношения порядка между операциями в конкурентных транзакциях и применяется аппарат логического, полисиллогистического вывода для выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции. Обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации.
Действия
Действие - это базовая операция, выполняемая приложением над реплицированными данными. Оно хранится в журнале и становится доступным для анализа сразу после записи или реконструкции журнала. Мы будем рассматривать действие как структуру, состоящую из шести элементов:
целевой объект, идентифицирующий элемент (или элементы) данных, на которое направлено действие; если язык информационного моделирования допускает конструкции запросов, то целевой объект также может быть выражен в терминах запросов; статус, определяющий метод для динамической проверки, применено ли уже действие или нет; методы статуса не имеют побочных эффектов и возвращают логическое значение; предусловие, определяющее аналогичный метод для проверки, можно ли выполнить данное действие при текущем состоянии данных; операция - метод доступа или модификации элемента (элементов) данных, определяемого целевым объектом; предполагается, что операция не оказывает побочного эффекта на данные, не определенные явно как объект действия, но может нарушить их семантическую корректность в контексте наложенных ограничений и вносимых сторонних изменений; операция возвращает логическое значение, указывающее на успешное или неуспешное выполнение действия; тег, хранящий всю информацию, относящуюся к параметрам операции; этот элемент необходим для воспроизведения журналов и реконструкции данных; инверсия - метод инвертирования действия, позволяющий отменить принятые ранее изменения и вернуть данные в первоначальное состояние; реализация метода может быть связана как с изменением соответствующего признака в существующем экземпляре действия, так и с конструированием нового экземпляра действия с инвертированными свойствами.
В рамках рассматриваемой объектно-ориентированной метамодели целевым объектом действия может быть прикладной объект, группа прикладных объектов или целая популяция, определяемая некоторым объектным запросом. Объектом действия может быть также атрибут прикладного объекта или его отдельный элемент, если атрибут сложно структурирован, например, являясь некоторой коллекцией. В большинстве случае это прикладные объекты и их атрибуты.
Стандартный набор действий включает в себя операции создания, удаления, перемещения прикладного объекта, модификации атрибута или его элементов. Семантика операций может быть уточнена в зависимости от специфики рассматриваемого класса приложений. Например, в ряде случаев изменение атрибута целого типа может интерпретироваться как его увеличение или уменьшение на некоторое значение. Изменение атрибута, являющегося множеством элементов некоторого типа, может быть одновременно представлено как включение и/или исключение соответствующих элементов. Подобная детализация имеет смысл только в тех случаях, когда нарушения семантических ограничений проявляются на подобном уровне. Мы рассчитываем, что языки объектно-ориентированного моделирования позволяют конкретизировать репертуар и детальную семантику действий независимо от особенностей конкретного приложения и конкретной модели данных.
Граф реконсиляции
Граф (гиперграф) реконсиляции RG определим как набор пяти множеств (V = V1
V2 VC , E = ED EP), где: V1, V2 - множества вершин, соответствующих операциям исходных транзакций T' и T". VC - множество операций, применяемых в корректирующей транзакции. При проведении анализа каждой вершине на графе присваивается логический статус. Статус указывает, включается ли соответствующая операция в итоговый журнал или нет. ED, EP - множества ребер (гипер-ребер), которые соответствуют отношениям зависимости и порядка, установленным между операциями. Каждое ребро помечается семантическим ограничением, порождающим соответствующее отношение. Бинарные отношения графически представляются обычными линиями, а множественные отношения - прямоугольными элементами, опирающимися на узловые вершины.
Граф реконсиляции обладает рядом свойств, существенных для его конструктивного анализа. Так как предполагается, что каждая транзакция, участвующая в процессе реконсиляции, является корректной, ребра, соответствующие обратным импликациям t1 → ¬t2 и ¬t1 → t2, могут быть установлены только между вершинами, принадлежащим разным транзакциям. В то же время ребра, соответствующие прямым импликациям t1 → t2 и ¬t1 → ¬t2, могут появиться как внутри отдельных транзакций, так и в разных транзакциях. Аналогично, между парой вершин одной транзакции не может существовать противоположных отношений порядка, что противоречило бы возможности их одновременного применения.
Следующие свойства связаны с обобщающими идеями сильных цепей зависимости и предшествования.
Пусть RG(V,E) - граф реконсиляции. Путь v1(t1), v2(t2), ..., vn(tn)
V вдоль ребер зависимости e1(D1), e2(D2), …, en-1(Dn-1) ED, начинающийся в вершине v1(t1) и заканчивающийся в вершине vn(tn), назовем цепью зависимости (или vn зависит от v1), если только существует соответствующая последовательность отношений зависимости t1D1t2, t2D2t3, …, tn-1Dn-1tn, эквивалентная простой импликации t1Dtn.
Прямой зависимостью назовем цепь зависимости, эквивалентную импликации t1 → tn или ¬t1 → ¬tn. Обратной зависимостью будем называть цепь, эквивалентную импликации t1 → ¬tn или ¬t1 → tn.
В графе реконсиляции не существует циклов обратной зависимости. Если бы такой цикл был найден, это означало бы, что любой статус операции, приписанный ее вершине, не соответствует логическим отношениям. Это противоречит существованию тривиальных решений логической системы, в качестве которых всегда могут быть выбраны операции первой или второй транзакции.
Путь v1(t1), v2(t2), ..., vn(tn)
V на графе реконсиляции RG(V,E) вдоль ребер предшествования e1(P1), e2(P2), …, en(Pn-1) EP, начинающийся в вершине v1(t1) и заканчивающийся в вершине vn(tn), назовем цепью предшествования (или v1 предшествует vn), если только отношения предшествования P1, P2, …, Pn-1 устанавливают порядок t1 ∠ t2, t2 ∠ t3, …, tn-1 ∠ tn.В графе реконсиляции не существует циклов предшествования, содержащих только вершины какой-либо одной транзакции. В противном случае это также противоречило бы существованию тривиальных решений задачи.
Этапы реконсиляции
В предлагаемом подходе общий процесс реконсиляции включает в себя семь этапов, представленных на Рис. 1:
Рис. 1.Основные этапы процесса реконсиляции
Сравнение и гармонизация: На первом этапе две расходящиеся реплики сравниваются между собой для выявления различий и реконструкции журналов. Даже если во время сессии велась постоянная журнализация, и все изменения зафиксированы, проводится дополнительный анализ, необходимый для выявления эквивалентных представлений в сравниваемых репликах и их гармонизации. Семантический анализ: Все операции транзакций из двух журналов анализируются с учетом семантики самих операций и семантики ограничений для элементов данных; эти ограничения определяются формально специфицированной информационной моделью. Между операциями устанавливаются отношения зависимости и отношения порядка (предшествования). Заметим, что проводимый на этой стадии семантический анализ охватывает как статические, так и динамические зависимости, которые могут быть реально проверены лишь с учетом текущего состояния элементов данных и фактических параметров операций транзакций. Поэтому мы считаем, что результаты, полученные на данном этапе, могут иметь различный уровень доверительности. Выявленные статические зависимости и отношения - абсолютно достоверны (необходимы и достаточны для корректности результирующей транзакции), динамические зависимости и отношения - предположительно достоверны (достаточны, но вовсе не необходимы для корректности транзакции) и поэтому в ряде случаев могут быть проигнорированы и уточнены на более поздних этапах валидации и коррекции. Декомпозиция и редукция: На основе анализа отношений определяются классы эквивалентности, импликативные цепочки и свободные группы операций. Для сформированных групп операций переустанавливаются отношения зависимости с другими операциями и группами. Целью данного этапа является уменьшение количества логических элементов (переменных и отношений) при логическом анализе транзакций и предотвращение комбинаторных проблем, обычно возникающих на последующих этапах. Планирование: Строятся возможные варианты результирующей транзакции, которые удовлетворяли бы всем выявленным отношениям зависимости и порядка и тем самым гарантировали бы ее корректность.
Во внимание принимается также требование наиболее полного покрытия результирующей транзакцией множеств операций в исходных транзакциях, поскольку именно этим определяется ее функциональная содержательность. В случаях, когда число приемлемых вариантов слишком велико, может быть построен план реконсиляции, который бы учитывал возникшие конфликты и определял альтернативные способы их разрешения, например, на основе дерева принятия решений. Валидация: Если в сопутствующем анализе игнорировалась часть ранее установленных (предположительно достоверных) отношений, они должны быть перепроверены с учетом фактического текущего состояния данных и значения параметров операций, поскольку только в этом случае можно гарантировать корректность итоговой транзакции. В случае обнаружения нарушений анализируемые варианты транзакций отвергаются, а ранее построенные планы реконсиляции уточняются путем исключения заведомо неприемлемых решений. Коррекция: Если содержательные решения не былы найдены (например, были найдены лишь тривиальные решения, состоящие в принятии всех операций первой или второй транзакции), то конструктивным подходом может оказаться ослабление предположительно достоверных отношений между операциями и пересмотр результатов семантического анализа. Если на этапе валидации были выявлены нарушения, но все-таки желательно представить критичные операции в результирующей транзакции; могут быть применены корректирующие методы, вносящие необходимые исправления и переводящие транзакцию и данные в корректное состояние. В обоих случаях процесс возвращается к более ранним этапам реконсиляции; Функциональный отбор: Наконец, решения, прошедшие этап валидации, ранжируются и отбираются пользователем согласно функциональным требованиям, предъявляемым к результатам реконсиляции. При наличии плана пользователь последовательно уточняет детали итоговой транзакции, включая в ее состав требуемые операции. С целью автоматизации подобных действий могут быть определены и применены политики исключения и консолидации, основанные на априорно заданных функциональных критериях и приоритетах.
В настоящей статье мы сосредоточимся на втором, третьем и четвертом этапах, охватывающих семантический анализ транзакций с использованием формальных спецификаций прикладной информационной модели, а также методы логического, прежде всего, полисиллогистического вывода для поиска решений рассматриваемой постановки задачи реконсиляции. Методы семантической декомпозиции транзакций более подробно обсуждаются в нашей работе [].
Литература
| 1.обратно | Y. Saito, M. Shapiro. Optimistic Replication // In ACM Computing Surveys, Vol. 37, No. 1, March 2005, pp. 42-81. |
| 2.обратно | ISO 10303-11: 1994, Industrial automation systems and integration - Product data representation and exchange - Part 11: Description methods: The EXPRESS language reference manual. |
| 3.обратно | Unified Modeling Language (UML), Version 2.0 |
| 4.обратно | The Object Data Standard: ODMG 3.0. eds. R.G.G. Cattel, D.K. Barry. Morgan Kauffmann, 2000. |
| 5.обратно | А.Д. Закревский. Логика распознавания. - Мн.: Наука и техника, 1988.- 118 с. |
| 6.обратно | J.F. Allen, G. Ferguson. Actions and Events In Interval Temporal Logic. // In Technical report 521, University of Rochester, Computer Science Department, July 1994, pp.1-59. |
| 7.обратно | ISO 10303: 1994, Industrial automation systems and integration - Product data representation and exchange. |
| 8.обратно | |
| 9.обратно | K. Ramamritham, P. Chrysanthis. Executive Briefing: Advances in Concurrency Control and Transaction Processing. IEEE Computer Society Press, 1997. |
| 10.обратно | Semenov V.A., Karaulov A.A., Semantic-Based Decomposition of Long-Lived Transactions in Advanced Collaborative Environments. // Proceedings of 6 European Conference on product and process modeling, ECPPM 2006, Valencia, September 11-15, 2006, ISBN 10: 0-415-41622-1, pp.223-232. |
| 11.обратно | Семенов В.А., Морозов С.В., Тарлапан О.А. Инкрементальная верификация объектно-ориентированных данных на основе спецификации ограничений. // Труды ИСП РАН, 2004, стр. 23-55. |
| 12.обратно | Semenov V.A., Bazhan A.A., Morozov S.V., Tarlapan O.A. Efficient Verification of Product Model Data: an Approach and an Analysis. // Proceedings of 22nd Conference on Information Technology in Construction, CIB-W78, Dresden, July 19-21, 2005, ISBN:3-86005-478-3, pp. 261-268. |
| 1(к тексту) | Работа поддержана грантом Президиума РАН в рамках программы фундаментальных исследований "Математические и алгоритмические проблемы информационных систем нового поколения". |
Логический анализ
Реализация намеченного подхода тесно связана с проведением логического анализа отношений зависимости и порядка, выявленных между операциями в конкурентных транзакциях на этапе семантического анализа. С целью формализации этапа решения предлагается использовать представление логической системы отношений в виде графа и/или матрицы реконсиляции и применить для эффективного поиска решений аппарат математической логики, в частности, полисиллогистический вывод и методы интервальной темпоральной логики. При этом декомпозиция и редукция логической системы рассматриваются и как самостоятельные этапы общего процесса реконсиляции, предваряющие непосредственный поиск решения, и как алгоритмические элементы единого метода, распространяемого на все переменные и отношения формализованной логической системы. Главной особенностью рассматриваемого метода является поиск непротиворечивых, семантически корректных решений, удовлетворяющих всем логическим отношениям, при обеспечении их полноты и репрезентативности. Последнее свойство принципиально для обсуждаемой задачи, поскольку для функциональной содержательности решения важно включить в итоговую транзакцию как можно больше операций исходных транзакций.
В случаях, когда в логической системе присутствуют только бинарные отношения, удобно иллюстрировать применение метода с помощью введенного графа реконсиляции, имеющего прозрачную графическую нотацию. Для представления множественных отношений в логической системе естественным выглядит обобщение понятия на гиперграф, однако мы предпочитаем использовать эквивалентное представление в виде матрицы реконсиляции. В настоящей статье рассматривается метод анализа с использованием графа реконсиляции.
Логический вывод на графе реконсиляции
Обсудим метод, использующий графическую нотацию для графа реконсиляции на Рис. 5. Вершины графа изображены окружностями и помечены символами операций. Каждая вершина располагается в одной из областей, соответствующих исходным транзакциям и, возможно, применяемой корректирующей транзакции. На диаграмме области исходных транзакций располагаются на противоположных сторонах и отделяются от центральной области корректирующей транзакции двумя вертикальными линиями. В случаях, если коррекция отсутствует, на диаграмме размещаются лишь области исходных транзакций, отделенные друг от друга одной вертикальной линией.
Бинарные отношения зависимости между операциями изображаются дугами, помеченными упорядоченными парами черных и/или белых кружков, бинарные отношения предшествования - стрелками. Строгие отношения зависимости представляются сплошными дугами, а нестрогие отношения - пунктирными дугами. Строгие отношения предшествования заканчиваются темными стрелками, а нестрогие отношения предшествования заканчиваются светлыми стрелками. При использовании некоторых визуальных элементов метода полисиллогистического вывода [] графическая нотация обеспечивает прозрачную и непротиворечивую интерпретацию обсуждаемой задачи. Для представления множественных отношений зависимости и порядка могут быть добавлены необходимые визуальные элементы, соответствующие ребрам соответствующего гиперграфа реконсиляции. На Рис. 6 приведен пример графа реконсиляции для рассмотренных выше транзакций.
Рис. 5.Графическая нотация элементов графа реконсиляции.
Опишем предлагаемый метод логического вывода, используя представленную графическую нотацию. Для выделения цепей зависимости и определения того, какие вершины могут зависеть от заданной вершины, удобно использовать следующее визуальное правило. Заметим, что цепями зависимости в графе реконсиляции являются только те цепи, ребра которых инцидентны общим вершинам с чередующимися цветами кружков. Это объясняется тем, что пара цветов, присваиваемая отношению импликации, соответствует запрещенной комбинации статусов операций, при этом черный цвет обозначает статус включения, а белый - исключения.
Таким образом, чередование цветов в инцидентных ребрах порождает цепочки логического вывода и соответствующие зависимости.
Рис. 6. Пример графа реконсиляции.
Общая схема метода вывода представляется следующими этапами.
На первом этапе все операции исходных транзакций объединяются в один временный журнал.
На втором этапе проводится поиск циклов прямой зависимости. Вершины найденных циклов формируют классы эквивалентности для операций, или, другими словами, множества операций, которые включаются в итоговую транзакцию только совместно. Таким образом, осуществляется декомпозиция транзакций на семантически связанные группы операций. В конечном итоге это приводит к снижению числа независимых переменных в решаемой логической системе, поскольку статус любой из вершин цикла однозначно определяет состояния всех остальных вершин.
На третьем этапе выявляются подобные цепи - логически эквивалентные цепи зависимости, начинающиеся и заканчивающиеся в одних и тех же вершинах графа. В результате проводимой редукции логической системы из анализа исключаются избыточные отношения и зависимые переменные, связанные с внутренними вершинами подобных цепей.
На заключительном этапе проводится поиск вершин, порождающих конфликты. Это вершины, инцидентные ребрам обратной зависимости, а также вершины, образующие циклы предшествования. Согласно применяемым политикам реконсиляции и решениям пользователя, операции, соответствующие конфликтным вершинам, последовательно удаляются из журнала. Вместе с удаляемой операцией из журнала исключаются все зависимые операции с вершинами, располагающимися вдоль цепей прямой зависимости от исходной вершины. Для оставшихся вершин пересматривается их возможность порождать конфликты. Например, если удалить некоторую вершину из цикла предшествования, то оставшиеся вершины становятся неконфликтными относительно данной группы отношений. После разрешения конфликтов, оставшиеся в журнале операции упорядочиваются согласно отношениям предшествования. Полученная в результате транзакция удовлетворяет всем наложенным семантическим ограничениям и предусловиям, необходимым для корректного воспроизведения журнала.
Представленный метод был изложен в предположении строгих необходимых отношений зависимости и порядка между операциями транзакций. Он естественным образом обобщается на нестрогий случай в результате инициирования процесса семантической реконсиляции с наиболее полной системой ограничений и ее последовательного ослабления. Однако полученные результаты нуждаются в дополнительной валидации, а при выявленных нарушениях - и в возможной дополнительной коррекции. Поскольку коррекция вносит новые изменения, которые могут конфликтовать с операциями исходных транзакций, процесс должен быть повторен, начиная с этапа семантического анализа.
Организация более сложного итерационного процесса сама по себе не гарантирует нахождение решения. Однако решения, полученные таким образом, являются более значимыми, поскольку обеспечивают полноту представления результирующей транзакции. В случае неудачи метод допускает возвращение к предыдущим стадиям решения, учитывающим большее количество ограничений. Заметим, что тривиальные решения задачи всегда существуют, и применение метода в результате возврата к ее строгой исходной постановке гарантирует их нахождение.
Общий подход к реконсиляции
В соответствии с главным принципом оптимистической репликации, приложения, выполняющиеся в распределенной среде, находятся либо на этапе изолированного исполнения, либо на этапе реконсиляции. При изолированном выполнении приложение оперирует локальной репликой разделяемых данных, приводя их в некоторые новые состояния. Все выполняемые действия записываются в журналах транзакций, являющихся упорядоченными множествами локально применяемых операций. Все действия детерминированы и обратимы. Применение всех операций, занесенных в журнал, к начальной версии данных должно приводить к той же окончательной версии. И наоборот, применение обратных операций в противоположном порядке должно возвращать данные из конечного состояния в первоначальное состояние.
Неважно, ведется ли журнал в приложении постоянно или реконструируется путем сравнения начальной и текущей версий данных. В этом отношении мы следуем смешанному классу методов (hybrid state-transfer and operation-transfer methods), охватывающему и анализ изменений в состоянии данных и контроль последовательностей выполнения операций в транзакциях. В ряде случаев, например, при определении и проверке предусловий для операций учет порядка их выполнения может быть исключен из анализа без потери содержательности результатов для приложения. Однако в дальнейшем мы будем рассматривать наиболее общий случай.
Будем считать, что транзакции корректны в том смысле, что они могут быть корректно воспроизведены на основе журналов и гарантированно приводят к семантически целостному и функционально значимому представлению данных. Это важное допущение мотивируется тем, что используемые приложения, запущенные на локальной станции и обрабатывающие локальную реплику данных, работают правильно. В этом предположении, если начальное состояние данных было корректно, то корректная транзакция должна порождать итоговое состояние, удовлетворяющее всем семантическим ограничениям целостности и несущее необходимый функциональный смысл, определяемый пользователем.
Одним из главных преимуществ обсуждаемого подхода является возможность сохранять свойства целостности при реконсиляции данных или, более точно, реконсиляции соответствующих журналов транзакций. Требование поддерживать семантическую целостность реплицированных данных рассматривается в нашем исследовании как базовый принцип функционально содержательной реконсиляции.
Отношения зависимости и порядка
Отношения зависимости между операциями D определяются логическими операторами отрицания и импликации следующим образом. Для операций t1, t2
T, если t1 → t2, то журнал должен содержать t2 при условии, что он содержит t1. Если ¬t1 → ¬t2, то в журнале должна отсутствовать операция t2, если в нем отсутствует операция t1. Эти отношения несимметричны, рефлексивны и транзитивны. Для операций t1, t2 T, если t1 → ¬t2, то в журнале не может присутствовать t2, если он содержит t1. Если ¬t1 → t2, то журнал должен содержать t2, если в него не входит t1. Эти отношения симметричны, не рефлексивны и не транзитивны. Эти четыре логические отношения с характеристическими функциями, приведенными в Таблице 1, рассматриваются как основные отношения зависимости. Также мы считаем полезным использование симметричных отношений эквивалентности t1 ~ t2 ≡ t1 → t2 
t2 → t1 и взаимоисключения t1 ⊕ t2 ≡ t1 → ¬t2 ¬t1 → t2. Отношение эквивалентности устанавливается между двумя операциями t1, t2 T и означает, что эти операции могут встречаться в транзакции T только совместно. Отношение взаимоисключения между t1, t2 T обязывает транзакцию T включать в себя либо t1, либо t2 и запрещает содержать обе эти операции или ни одну из них.
| 0 | 0 | 1 | 1 | 0 | 1 | 0 |
| 0 | 1 | 1 | 1 | 1 | 0 | 1 |
| 1 | 0 | 0 | 1 | 1 | 0 | 1 |
| 1 | 1 | 1 | 0 | 1 | 1 | 0 |
Таблица 1.Характеристические функции бинарных отношений зависимости.
В некоторых случаях приходится рассматривать более сложные множественные отношения между операциями. В общем виде они представляются характеристической функцией D(t1, t2, t3, …) и соответствующей таблицей значений, подобной Таблице 1.
В качестве примера рассмотрим множественное отношение кардинальности D(n:m)(t1+,…, t+I+ , t1-,…, t-I-). Данное отношение связано с ограничениями кардинальности ассоциаций и размерности коллекций элементов данных в объектно-ориентированной модели.
Оно считается выполненным, если
n ≤ card( T+ ) - card( T- ) ≤ m, где
T+ = { ti+, i
D(m:m)(t1+,…, t1-, …).
| t1+ T | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| t2+ T | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| t1- T | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| t2- T | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| D(0:0) (t1+,t2+,t1-,t2-) | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
| D(1:1) (t1+,t2+,t1-,t2-) | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
| D(2:2) (t1+,t2+,t1-,t2-) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
Часто требуется удовлетворить некоторое ограничение c = с(x1, x2, …), выраженное алгебраическим образом с помощью соответствующей логической функции нескольких переменных. Если конкурентные транзакции содержат операции модификации элементов данных, являющихся фактическими параметрами функции ограничения, то возможным способом сохранить целостность является принятие всех операций модификации первой транзакции или всех операций модификации второй транзакции. В этом случае между операциями устанавливается отношение алгебраической зависимости Dc (t1', t2', …,t1'', t2'',…), где операции первой транзакции t1', t2'
T' и операции второй транзакции t1'', t2'' T' модифицируют элементы данных, на которые наложено ограничение c(x1, x2,…).
Будучи выполненным, данное отношение приводит к выделению классов эквивалентности для операций каждой транзакции и исключению ситуаций одновременного их применения в результирующей транзакции:
D c (t1', t2',…,t1'', t2'',…) ≡ t1' ⊕ t1''
t1' ~ t2' t2' ~ t3' … t1'' ~ t2'' t2'' ~ t3'' …Отношение порядка или предшествования операций в транзакции P определим следующим образом. Для операций t1, t2
T, если t1 ∠ t2, то операция t1 должна появиться до операции t2 (не обязательно непосредственно перед ней) в любом решении, которое одновременно содержит операции t1 и t2. Отношение порядка несимметрично, не рефлексивно, но транзитивно. Так как отношение подразумевает наличие обеих операций в одной транзакции, отношение t1 ∠ t2 может быть установлено только между теми операциями, которые не связаны отношениями зависимости t1 → ¬t2 и t1 ⊕ t2 непосредственно или косвенно через другие отношения.Обсуждаемые отношения являются строгими в том смысле, что если операции не удовлетворяют некоторым установленным отношениям, то транзакция необходимо становится некорректной, что означает невозможность ее выполнения или потерю целостности воспроизводимыми данными. В ряде случаев могут быть рассмотрены более слабые отношения, обозначаемые
D
и P, которые совпадают со строгими отношениями D, P за исключением того, что они имеют достаточный, но не необходимый характер для корректности транзакции. Другими словами, иногда они могут быть не выполнены, не нарушая условия корректности транзакции и целостности данных. Поскольку риск нарушения все равно остается, предварительные решения (транзакции и данные), полученные без учета подобных отношений, должны быть дополнительно проверены на более поздних этапах рассмотренного выше процесса реконсиляции.Понятие корректной транзакции
Пусть X - область значений, которые могут принимать данные рассматриваемой прикладной объектно-ориентированной модели, C(x) ≡ {ci(x) | i =1,..,I} - система ограничений, наложенных моделью на состояние x
X и принимающих логическое значение true, если ограничение удовлетворено, и false, если оно нарушено. Если все ограничения удовлетворены в точке x X, тогда мы говорим, что находится в корректном состоянии, или C(x) = true. Если хотя бы одно из условий не выполняется, т.е. ci(x) = false, то состояние x X считается некорректным, что выражается соответствующим образом: C(x) ≡ c1(x) c2(x) … cI(x) = false.
Для некоторых ограничений ci (x) могут быть определены корректирующие методы rij
R таким образом, что если ci (x) = false, то применение метода приводит данные в состояние, удовлетворяющее ранее нарушенному ограничению, т.е. x' = rij(x), ci (x') = true. Мы считаем, что для любого ограничения ci (x), i = 1,…I могут быть определены соответствующие корректирующие методы rij R. Однако они должны применяться с учетом всех наложенных ограничений ci' (x), i' ≠ i, i' = 1,…I и возможного нарушения некоторых их них, если они уже были удовлетворены.
Если данные находятся в состоянии x
X, то выполнение действия t(xt, pt) с параметрами pt над целевым объектом xt = PrDt x, являющимся некоторой проекцией x на область определения операции Dt, приведет к переводу целевого объекта в состояние x't X, а всех данных - в состояние x' X. Мы будем обозначать это следующим образом: x't = t(xt) и x' = t(x). Отдельно выполненное действие может нарушать целостность данных, т.е. если C(x) = true, то C(x'), где x' = t(x), не обязательно принимает значение true. Но мы требуем, чтобы любая корректная транзакция вида T = { tk (xt, pt) | k = 1,…,K } сохраняла целостность данных. Если транзакция T корректна и начальное состояние данных корректно (C(x) = true), то C(x') = true, x' = T(x).
При этом не требуется, чтобы каждое действие tk
T или некоторые группы действий tk1, tk2,…, tkn T перманентно сохраняли целостность данных во время выполнения транзакции.Для применения каждое действие корректной транзакции должно удовлетворять соответствующему предусловию. Поскольку действия в транзакциях не подчиняются коммутативным свойствам, порядок их применения существенен как для выполнения предусловий, так и для конечных результатов. Поэтому вводимое понятие корректной транзакции предполагает выполнимость всех определенных предусловий для действий и учитывает порядок их следования. В дальнейшем рассматриваются только корректные транзакции за исключением, естественно, некоторых временных представлений журналов.
Теперь определим возможные виды отношений между операциями. Временный журнал транзакции T = T'
T'' - это упорядоченное множество действий, полученное путем объединения журналов реконсилируемых транзакций T' и T'', причем если x - начальное состояние данных и x' и x'' - расходящиеся реплики, то x' = T'(x) и x'' = T''(x).Примеры формального анализа транзакций
Обратимся к следующей демонстрационной модели, формально описанной на языке EXPRESS (см. Рис. 4). Модель описывает объектный тип данных A с вещественными атрибутами x, y, z, целочисленным идентификатором id и квалификационным именем q, представленным множеством из трех строк. Модель определяет также объектные типы данных B и C, содержащие необязательную и обязательную ссылки соответственно на экземпляр объекта типа A.
Определение типа A содержит правила Wr1, Wr2, ограничивающие допустимую область значений атрибутов x, y, z, а также правило уникальности Ur1 для значений атрибута id, действие которого распространяется на всю популяцию объектов типа A.
Пусть начальное состояние данных x = {a
Рис. 4. Демонстрационная модель данных, формально описанная на языке EXPRESS
Аналогичные отношения t1' → t2', t1' ⊕ t2'', t1' ∠ t2', и t1'' ∠ t2'' могут быть установлены для операций в сформированном временном журнале T'
T'' = {t1' = del(a), t2' = wr(b1.ref, 0), t1'' = new(b1B), t2'' = wr(b1.ref, a), …}.
Отношение t1' → t2' вытекает из того, что удаление объекта a требует обнуления соответствующей ссылки b1.ref, указывающей на него. Отношение t1' ⊕ t2'' появляется, потому что операции удаления объекта a в первой транзакции и установки на него ссылки b1.ref во второй транзакции являются взаимоисключающими.
Для временного журнала T'
T'' = {t1' = rm(a.q,…), t2' = in(a.q,…), t1'' = rm(a.q,…), t2'' = in(a.q,…) …}, чтобы сохранить атрибут q в корректном состоянии, необходимо потребовать, чтобы количество элементов соответст-вующего множества было ровно 3. Предполагая, что начальное состояние было корректным и применение каждой транзакции не нарушает целостности, мы устанавливаем отношение кардинальности D(0:0)(t2'+, t2''+, t1'-, t1''-). Это означает, что количество добавляемых элементов равно количеству исключаемых элементов, и мощность множества остается неизменной.Рассмотрим отношения между операциями, порождаемые правилами ограничения области значений. Для корректности итоговой транзакции с временным журналом T'
T'' = {t1' = wr(a.x), t2' = wr(a.y), t1'' = wr(a.z), …} требуется выполнение отношения алгебраической зависимости DWr1(t1', t2', t1''). В этом случае в итоговую транзакцию включаются все участвующие в ограничении операции первой или второй транзакции, и ограничение будет гарантированно удовлетворено. Отметим, что данное отношение носит предположительный характер, являясь достаточным, но не необходимым условием корректности транзакции. Поэтому при необходимости оно может быть снято на этапе семантического анализа транзакции, но тогда связанное с ней ограничение обязано быть проверено на последующем этапе валидации. Аналогичный вывод справедлив для отношения DWr2(t1', t2', t1''). Однако более детальный анализ показывает, что данное отношение следует исключить из рассмотрения, так как модифицируемые в различных транзакциях атрибуты появляются в различных термах конъюктивной нормальной формы предиката ограничения области значений.Наконец, рассмотрим отношения, устанавливаемые для ограничения уникальности. Предположим, что в каждой транзакции создается объект типа A, и инициализируется его обязательный атрибут id. Журнал для представления транзакции выглядит следующим образом: T'
T'' = {t1' = new(a1A), t2' = wr(a1.id, id1), t1'' = new(a2A), t2'' = wr(a2.id, id2),…}. Чтобы удовлетворить ограничение уникальности значений атрибута id, в дополнение к отношениям импликации t2' → t1', t2'' → t1'' и предшествования t1' ∠ t2', t1'' ∠ t2'' следует установить отношение исключения t1' ⊕ t2''. Однако такое отношение может оказаться слишком сильным, так как присваиваемые значения идентификаторов могут различаться. Поэтому здесь следует применить нестрогую форму отношения. Заметим, что даже если в дальнейшем на этапе валидации будет обнаружено, что идентификаторы случайно совпали, существует возможность переназначить их с использованием корректирующих методов.Конечно, приведенные примеры не исчерпывают все содержательные случаи семантического анализа транзакций. Тем не менее, они описывают типовые ситуации, возникающие на данном этапе реконсиляции, и иллюстрируют возможности применения формального, основанного на спецификациях прикладной модели данных, подхода. Отметим только, что для определения алгебраических зависимостей между данными и установления соответствующих отношений между операциями транзакций могут быть использованы методы инкрементального анализа и верификации данных [, ].
Роль модельно-ориентированного подхода
Модельно-ориентированный подход становится важным доминирующим направлением в инженерии программного обеспечения, критичного по отношению к требованиям мобильности, интероперабельности, развертываемости в разнородных средах. Деятельность международных сообществ по разработке соответствующих информационных стандартов и многофакторных прикладных моделей, прежде всего, в рамках ISO 10303 (STEP - Standards for Representation and Exchange of Product Model Data) [] и OMG MDA (инициатива Model-Driven Architecture группы индустриальных компаний Object Management Group) [] способствует развитию этих тенденций.
Вместе с тем, применение модельно-ориентированного подхода при построении прикладных интегрированных комплексов для проведения масштабных междисциплинарных проектов в науке и промышленности, обнаруживает ряд фундаментальных проблем. Прежде всего, это проблема синергетической организации работ с участием большого числа партнеров проекта, вовлеченных в единую творческую и производственную деятельность, но профессионально, организационно и географически отделенных друг от друга. Традиционные решения, использующие в качестве ключевых компонентов интеграции системы управления базами данных и системы документооборота, как правило, имеют довольно ограниченное применение. Они либо не обеспечивают целостность проектной информации, либо существенно ограничивают возможности участников работать одновременно, что критично сказывается на качестве, стоимости и сроках проведения работ.
Обеспечение эффективного мультидоступа к проектным данным при необходимой централизации управления ими и существенно распределенном, автономном и продолжительном характере проведения индивидуальных пользовательских сессий представляется в данном случае наиболее критичным. Предпринятые попытки ослабления базовых принципов ACID на основе идей последовательной целостности (serial consistency), использования версий данных (multiversion concurrency), применения специальных протоколов транзакций (transaction access patterns), а также разработки специальных механизмов альтруистических блокировок (altruistic locks) себя не оправдывают [].
Вместе с тем, хорошо известны примеры успешного применения в ряде приложений оптимистической репликации. Это популярные распределенные сервисы UseNet; персональные помощники PDA (Personal Digital Assistants); мобильные базы данных, включая широко известную реализацию Bayou; системы совместной разработки программного обеспечения, в частности, CVS (Concurrent Versions System). Однако в применяемых в них методах игнорируются сложные семантические зависимости между данными и не обеспечивается желаемая целостность итогового представления.
Например, реализуя типовые средства синтаксической реконсиляции текстовых документов, CVS не позволяет контролировать и, тем более, гарантировать семантическую корректность итоговых текстов программ на том или ином языке реализации. Однако, если в системах программной инженерии текстовые данные всегда могут быть скорректированы непосредственно программистами, в научных и промышленных приложениях, оперирующих со сложно структурированными моделями, их коррекция не может быть осуществлена усилиями пользователей.
В связи с этим естественной выглядит попытка разработки и применения модельно-ориентированного подхода к семантической реконсиляции с использованием формальных спецификаций модели данных. Подобные спецификации предоставляют дополнительные возможности для статического и динамического анализа зависимостей между элементами данных и выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции.
Исследования в этой области в настоящее время привлекают как коммерческие компании, так и многочисленные университетские коллективы.
Семантическая реконсиляция прикладных данных на основе моделей
В.А. Семенов, С.Г. Ерошкин, А.А. Караулов, И.В. Энкович,
Труды Института системного программирования РАН
Семантический анализ транзакций
Процесс реконсиляции состоит в объединении журналов изменений с тем, чтобы построить новый журнал и, воспроизведя его, реконструировать согласованное представление реплицированных данных. В идеальном случае полученный журнал должен содержать все действия исходных журналов и приводить к представлению данных, которое бы удовлетворяло необходимым семантическим ограничениям и пользовательским требованиям. Тем не менее, простые приемы исключения и консолидации семантически подобных действий в совместном журнале не обеспечивают выполнения необходимых ограничений и нарушают целостность итогового представления данных.
Вместо этого мы предлагаем использовать информационную модель данных для более детального анализа операций транзакций и применения методик группирования и упорядочивания для перманентной поддержки данных в целостном состоянии.
Типы данных и виды ограничений
Объектно-ориентированные языки моделирования, такие как EXPRESS, UML/OCL, ODL/OQL, предоставляют широкий спектр декларативных и императивных конструкций для описания структур данных и накладываемых на них семантических ограничений.
В частности, в языке EXPRESS определяются простые типы данных с общепринятой семантикой: вещественный, целый, числовой, булевский, логический, строковый, двоичный строковый. Сложные типы охватывают четыре вида коллекций: списки, множества, массивы, мультимножества, а также перечисления, выборки и переопределяемые типы, уточняющие семантику основных типов. Для объектных типов предоставляются развитые механизмы множественного наследования, специализации атрибутов, полиморфного определения производных методов, декларации ограничений, позволяющие пользователям определять сложные модели данных.
На Рис. 2 представлена общая классификация типов, поддерживаемых языком EXPRESS. Полужирным курсивом отмечены исходные типы. Стрелки показывают отношения наследования между ними. Конструкции для определения типов пользователем отмечены обычным шрифтом.
Рис. 2.Классификация исходных типов языка EXPRESS
В зависимости от контекста определения различаются три основных вида ограничений: правила для простых пользовательских типов данных, локальные правила для объектных типов и глобальные правила для наборов объектных типов (Рис. 3).
Кроме неявно предполагаемых условий соответствия присваиваемых значений их типам, данные виды ограничений позволяют задавать:
ограничение длины символьных и двоичных строк; мощность коллекций (множеств, мультимножеств, списков, массивов); кардинальность прямых и обратных ассоциаций в объектах; уникальность элементов в коллекциях-множествах; уникальность значений атрибутов (и групп атрибутов) на объектных популяциях; атрибуты с обязательно установленными значениями; массивы с установленными элементами; область значений для отдельных атрибутов, объектов и целых объектных популяций; область значений задается предикатом, алгебраически выра-женным декларативными и императивными конструкциями языка (в том числе управляющими конструкциями, функциями, процедурами и т.д.).
Рис. 3. Классификация видов ограничений EXPRESS
Для получения более подробного описания можно обратиться к упомянутым выше стандартам, регламентирующим языки.
и прикладная проблема, тесно связанная
Семантическая реконсиляция - фундаментальная научная и прикладная проблема, тесно связанная с применением современных технологий оптимистической репликации в распределенных системах и имеющая индустриально важные приложения, такие как системы коллективной инженерии (concurrent engineering environments), мобильные базы данных, распределенные сервисы, семантические сети [].
Использование в подобных приложениях оптимистической репликации позволяет отказаться от необходимой централизации управления распределенными информационными ресурсами, свойственной пессимистическим моделям транзакций, и обеспечить возможность эффективной одновременной работы пользователей и приложений с реплицированными версиями данных. Однако необходимость обнаружения и разрешения конфликтов в конкурентных транзакциях после их применения делают постановку задачи реконсиляции довольно нетривиальной. Требования корректности и полноты реконструируемой итоговой транзакции, а также условия семантической целостности результирующего представления данных существенно усложняют поиск допустимых решений.
В настоящей работе обсуждается предложенный подход к семантической реконсиляции с использованием формальных спецификаций модели данных. Предполагается, что спецификации представлены декларативным образом на объектно-ориентированных языках EXPRESS [], UML/OCL [], ODL/OQL [] (или на подобных им) и охватывают как структуры данных, так и заданные на них семантические ограничения.
На основе формального анализа конкурентных транзакций выявляются возможные отношения между элементами данных и операциями, и применяется логический вывод для их семантически корректного и функционально содержательного слияния. При подобном подходе операции транзакций рассматриваются как объекты системы посылок и заключений, а отношения зависимости и порядка между ними - как правила логического вывода. Выбранная система отношений позволяет, с одной стороны, промоделировать сложные семантические зависимости между операциями транзакций, а с другой стороны - привлечь для решения рассматриваемой задачи хорошо развитый аппарат математической логики, в частности, методы полисиллогистического вывода [] и интервальной темпоральной логики [].
С целью обобщения рассматриваются бинарные и множественные отношения, а также учитываются возможные альтернативные способы задания отношений в аналитической и табличной форме.
Обсуждаемый подход относится к так называемому смешанному классу методов и допускает конструктивную реализацию в составе распределенных систем с традиционными клиент-серверной и равнозначной P2P архитектурами на основе поддерживаемых протоколов транзакций. Он также реализуем в автономных приложениях, использующих файловый обмен данными, посредством непосредственного сравнения версий данных и реконструкции журналов изменений.
Подход обладает рядом важных достоинств, связанных с гарантированным обеспечением целостности прикладных данных, которые определяются масштабными, семантически сложными моделями, при относительно невысоких вычислительных затратах. Возможности формализованного и содержательного применения подхода к широким классам приложений оптимистической репликации делают его привлекательным для реализации перспективных систем коллективной инженерии с долгими транзакциями и мобильных информационных систем с неустойчивым соединением и прерываемыми сессиями.
посвящен обсуждению общих аспектов применения модельно-ориентированного подхода к построению прикладных интегрированных систем и необходимости ослабления фундаментальных принципов ACID (атомарности, целостности, изоляции и долговечности) для приложений оптимистической репликации. В описывается общая схема процесса семантической реконсиляции, а также на примере языка объектно-ориентированного моделирования EXPRESS приводится классификация типовых элементов данных и семантических ограничений. Проведение семантического анализа конкурентных транзакций на основе введенной классификации основных видов отношений зависимости и порядка между операциями обсуждается в . Особое внимание уделяется установлению отношений на основе формального анализа семантических ограничений в прикладной модели данных. Процесс декомпозиции и редукции задачи с помощью определяемого графа и матрицы реконсиляции рассматривается в .В приводятся конструктивные утверждения относительно корректности постановки задачи и поиска решений на основе эквивалентных преобразований матрицы реконсиляции. В заключении обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации.
ориентированный подход обладает рядом важных
Представленный модельно- ориентированный подход обладает рядом важных конкурентных преимуществ, главным из которых является строгое обеспечение целостности результирующего реконсилированного представления данных и, как следствие, возможность эффективного применения в приложениях, использующих технологии оптимистической репликации и оперирующих масштабными, семантически сложными моделями данных.
Значительная универсальность, достигнутая за счет применения общего математического аппарата, не препятствует содержательному применению подхода к разнообразным классам приложений, включая системы коллективной инженерии с долгими транзакциями и мобильные информационные системы с прерываемыми сессиями. Благодаря использованию формальных методов статического анализа спецификаций прикладных моделей, удается преодолеть проблемы комбинаторного характера, свойственные многим другим методам. Важно отметить, что логический вывод является одним из наиболее затратных элементов предлагаемого подхода, поскольку число операций в конкурентных транзакциях и число установленных отношений между ними может быть значительно. Тем не менее, применение разреженных схем представления логических отношений и соответствующих матричных методов преодолевает эту проблему. Данный аспект является принципиально важным, поскольку позволяет существенно снизить вычислительную сложность и сделать возможным практическое применение подхода для важных научных и индустриальных приложений.
