Стратегическое планирование

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

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

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

Проект (Project)

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

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

За проект отвечает связанный организационный ресурс.

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

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

План (Plan)

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

План может быть создан как класс или как сотрудничество UML.

Многие проекты могут существовать как долгосрочные, управляемые в соответствии со стратегией, и могут дополняться краткосрочными тактиками.

Это моделируется связыванием проекта со Стратегической миссией, которая соответствует долгосрочной стратегии проекта, отношением Strategy Of Project, и с элементами Использование возможности, которые соответствует краткосрочным тактикам проекта, отношениями Tactics Of Project.

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

Планируемая деятельность (Plan Activity)

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

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

Планируемая деятельность может быть создана как деятельность (Activity), взаимодействие (Interaction), машина состояний (State Machine) или непрозрачное поведение (Opaque Behavior) UML.

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

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

Интервал времени (Time Interval)

Интервал времени – это тип данных, используемый для определения временного промежутка, на который могут ссылаться множество модельных элементов. Интервал времени определяется двумя строками: начальная дата и конечная дата. Формат дат не предписан, но должен соответствовать ISO 8601 (YYYY-MM-DD hh:mm:ss).

Экземпляр интервала времени обеспечивает средство для определения диапазона дат, которые могут быть связаны с другими элементами UPIA, чтобы указать ограничения во времени.

В модели UPIA, элемент интервал времени – это UML спецификация экземпляра, классификатором которой должен быть или тип данных TimeInterval из библиотеки модели UPIA, или специализация этого типа данных.

Примечание: Модельный элемент Интервал времени используется не только в планировании. Он может присоединяться к любому элементу UPIA, если требуется.

Веха (Milestone)

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

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

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

Прогноз (Forecast)

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

Дополнение диаграммы элементами стратегического  планирования

На следующем рисунке представлена диаграмма стратегии UK SAR, которая была показана в предыдущем выпуске, после дополнения некоторыми модельными элементами, связанными с планированием.

Рисунок 1. Модернизированная диаграмма стратегии предприятия.

Модернизированная диаграмма дополнительно включает:

• Временные рамки предприятия

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

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

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

• План проекта

Ответственный исполнитель проекта – Оперативная группа UK SAR.

Стратегическое управление ппроектом поддерживается Миссией предприятия.

Целью проекта является поставка возможности "Поиск и спасение".

Стратегический план приобретения возможности

Пример диаграммы стратегического плана ниже иллюстрирует, скорее, логику планирования, чем фактическое содержание работ по UK SAR.

Рисунок 2. Обзор проекта приобретения.

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

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

Диаграмма содержит некоторую дополнительную полезную информацию:

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

Эту информацию можно на диаграмме не показывать.

Обратите внимание:

• На диаграмме отсутствуют зависимости между возможностью и поддерживаемыми целями, которые были созданы на диаграмме стратегии (см. рис. 1 выше), хотя эти зависимости были автоматически созданы при размещении на диаграмме существующих элементов. Хорошая практика рекомендует размещать на диаграммах только то, что относится к делу. Зависимости были удалены из диаграммы вручную.
• Экземпляр интервала времени "Целевой выпуск 2" указывает только конечную дату интервала. Это объясняется тем, что начальная дата определяется отношением Project Phase. Удаление из модели начальной даты интервала тоже произведено вручную.[1]

Заключение к выпуску

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

Из новых, нужно упомянуть два инструмента платформы Jazz. Это IBM Rational Team Concert, инструмент поддержки коллективной разработки, и IBM Rational Project Conductor, инструмент для планирования и управления проектом.

Из более известных – это IBM Rational ProjectConsole, инструмент управления портфелем проектов.

Традиционный набор, IBM Rational Suite, не имел специализированных инструментов планирования и управления проектами. Но замечательные инструменты IBM Rational ClearQuest (управление запросами изменения) и IBM Rational RequisitePro (управление требованиями) мало того, что тесно интегрированы между собой, а еще интегрированы с самым, пожалуй, известным инструментом планирования Microsoft Project.

Я стараюсь, насколько возможно, автоматизировать свою работу и работу своих коллег, для чего "выдумываю" всякие приспособления, типа начального автоматического заполнения элементами модели анализа на основе информации модели прецедентов и т.п. Для планирования я использую длинную, но вполне логичную цепочку IBM Rational Software Architect <-> IBM RequisitePro <-> MS Project. Это стало возможным после появления в RSA возможности определять любой модельный элемент как требование RP. Но это отдельная тема.

Что касается проекта UK SAR, то мы продолжим усовершенствование плана проекта в последующих выпусках после детального изучения возможности "Поиск и спасение".