• краткое описание зависимости: обозначение, включающее пары компонент-источник зависимости и зависимый компонент;

• полное объяснение зависимости: пояснительный текст;

• тип зависимости: использует результаты, имеет общие ресурсы;

• Виды зависимости:

• определяет появление компонента: зависимый компонент воз­никает после разработки компонента-источника (например: со­здание и утверждение спецификации требуется осуществить к моменту программирования модуля);

• ожидает результата: какой, когда — плановая и критическая даты;

• ожидает окончания: когда — плановая и критическая даты;

• зависимость постоянно существует;

• зависимость существует в пределах итерации;

• зависимость охватывает разные итерации (указать, какие);

• текущий статус зависимости:

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

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

• критическая: требует немедленной реакции;

• ответственный за компонент-источник и за зависимый компонент: исполнители из коллектива разработчиков и их роли;

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

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

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

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

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