Методологии разработки программного обеспечения
Часть 5. Microsoft Solutions Framework
Основные компоненты и модели MSF
Проектирование компонентного ПО
Планирование архитектуры предприятия
Введение
Microsoft Solutions Framework (модель разработки приложений Microsoft) — это набор концепций и рекомендуемых моделей, которые позволяют разрабатывать и внедрять информационные системы на основе технологий и инструментальных средств Microsoft. Многие концепции MSF хорошо известны. MSF является одной из интерпретаций спиральной (циклической) модели разработки приложений и базируется на практических результатах организации распределенных вычислений и применения технологий «клиент-сервер» компании Microsoft, ее партнеров и заказчиков.
Главной целью MSF, как и любой методологии проектирования приложений, является создание рабочего приложения вовремя и в рамках установленного бюджета. MSF предлагает хорошо зарекомендовавшие себя практики планирования, разработки и внедрения информационных технологий. В то же время MSF не является простым набором инструкций, которым полагается следовать безоговорочно, — этот процесс достаточно гибок и расширяем. Основной сайт, посвященный методологии MSF: http://www.microsoft.com/msf.
 |
|
Основные компоненты и модели MSF
MSF содержит следующие модели:
• Team Model (Модель команды) — описывает коллектив, в котором работа одного сотрудника зависит от другого;
• Proccess Model (Модель процесса) — позволяет определить принципы планирования и контроля проектов;
• Application Model (Модель приложения) — помогает создавать приложения, максимально используя готовые компоненты;
• Enterprise Architecture Model (Модель архитектуры корпорации) — обеспечивает принятие решения по технологиям; она очень важна для эффективного использования новых технологий;
• Solution Desing Model (Модель проектирования решений) — показывает, каким должно быть приложение с точки зрения пользователя. Эта модель связывает приложение, команду разработчиков и процесс разработки;
• Infrastructure Model (Модель управления инфраструктурой) — определяет принципы управления пользователями в больших сетях;
• Total Cost of Ownership Model (Модель стоимости владения продуктом) — позволяет оценивать расходы на информационные технологии.
Базовыми компонентами методологии являются:
• Solution Development Discipline (SDD) — дисциплина разработки решений. Содержание этой дисциплины связано с уникальными моделями: моделью команды и моделью процесса, которые рекомендуется использовать для организации эффективных команд проектов и управления жизненным циклом проекта. SDD включает три фундаментальные модели MSF:
- масштабируемая модель команды разработки — описывает принципы организации группы людей, ответственных за разработку приложения,
- итеративная модель процесса разработки — описывает, как должен быть организован процесс,
- сетевая трехслойная модель приложения — описывает, какой должна быть структура приложения, удовлетворяющего современным требованиям;
• Designing Component Solutions (DCS) — проектирование компонентного ПО. Эта дисциплина направлена на поддержку процесса проектирования сложных моделей распределенных вычислений;
• Enterprise Architecture Planning — планирование архитектуры предприятия. С точки зрения Microsoft, это итеративный процесс, сосредоточенный на долгосрочном планировании, но при этом направленный на достижение результатов в максимально сжатые сроки;
• Infrastructure Deployment and Management — управление технологической инфраструктурой. Эта дисциплина содержит подход к процессу внедрения в масштабах предприятия как новых информационных технологий, так и отдельных программных продуктов и приложений.
Ниже мы рассмотрим ключевые модели, отличающие MSF от других коммерческих реализаций спиральной методологии разработки.
|
|
Процесс MSF
Модель процесса SDD представляет собой один из вариантов спиральной модели: когда один цикл внедрения близок к завершению, уже должен планироваться следующий. Это связано со скоростью изменения бизнес-процессов, а также с быстрым развитием информационных технологий. Сдвиг фаз нового цикла относительно предыдущего может быть разным для различных проектов. Последовательность фаз в витке является логической в смысле зависимости последующих фаз от предыдущих. Это не означает, что фазы выполняются во времени строго одна за другой и следующая фаза может начаться только по окончании предыдущей. Фазы могут выполняться параллельно и быть частично или полностью совмещенными по времени. Кроме того, сами фазы проекта носят итеративный характер. По достижении очередной вехи полученные материалы немедленно подвергаются проверке и оценке, результаты вызывают очередную итерацию уже проделанных работ, что не мешает начинать и продолжать дальнейшую работу в остальной части проекта.
Цикл (виток спирали) разработки включает четыре фазы и завершается выпуском версии продукта. Каждая фаза представляет собой определенную последовательность действий и завершается вехой (milestone).
• Первая фаза — Анализ (Envisioning). На данном этапе формируется представление о продукте на данном витке спирали. Это гарантирует, что разрабатываемый продукт будет соответствовать как текущим, так и перспективным целям компании, а также поможет скорректировать направление развития компании. Данная стадия требует глубокого осмысления целей проекта. Формирование представления позволяет избежать, например, инвестирования в незначительные или неэффективные проекты. В результате этой стадии составляется представление о продукте, определяются его функциональные возможности и оцениваются результаты. Если новый продукт получает одобрение, то составляется группа разработки проекта, задача которой — выработать концепцию продукта. На этом этапе фиксируются цели и определяется четкое направление разработки. Здесь же устанавливаются возможности конкретной версии продукта или службы и оцениваются тенденции развития продукта в следующих версиях. Вехой данной фазы является утверждение представления.
• Вторая фаза — Планирование (Planning). С точки зрения Microsoft, планирование — это процесс согласования требований потребителей и группы проекта, касающихся конечного продукта и направления разработки продукта. Это метод прогнозирования рисков, выработки приоритетов и оценки графика работ и необходимых ресурсов. Фаза планирования завершается одобрением плана проекта, который включает функциональную спецификацию — комбинированные планы для каждого члена группы в соответствии с требованиями модели команды и график работ. Функциональная спецификация достаточно детализирована, чтобы позволить группе проекта определить потребности в ресурсах и ее обязательства. Вехой данной фазы является утверждение плана проекта.
• Третья фаза — Разработка (Developing). Стадия разработки завершается реализацией возможностей продукта и проверкой их на практике. Группа разработки определяет промежуточные этапы выпуска продукта, каждый из которых включает полный цикл тестирования, отладки и внесения исправлений. На этом этапе потребители и группа разработки оценивают функциональные возможности продукта и проверяют оптимальность планов развертывания и поддержки. Разработка в целом завершается, а все нереализованные возможности документируются для включения в следующие версии. Вехой данной фазы является завершение разработки, альфа-версия (передается тестерам, пользователям, начинается устранение ошибок).
• Четвертая фаза — Стабилизация (Stabilizing). На этой стадии акцент переносится с разработки решения на проверку его работоспособности в реальных условиях и на полномасштабное тестирование. Стадия стабилизации завершается выпуском продукта, который передается группам развертывания и сопровождения. Группе проекта поручают создание следующей версии либо подключают к работе над другими проектам. Вехой данной фазы является релиз продукта.
Контрольными точками процесса являются вехи (milestones). Работа команды ориентирована на достижение вех, что сопровождается появлением и фиксацией того или иного отчуждаемого материала (документа, программы, протокола и т.д.). Веха — это время проведения инспекций (фазовых обзоров), на которых обсуждаются достигнутые результаты и принимаются решения. Перечисленные выше ключевые вехи являются внешними, то есть отчуждаемые материалы вехи согласуются с заказчиком. Очень важно, что каждая веха — это точка синхронизации, в которой происходит взаимное согласование точек зрения исполнителей (команды проекта), заказчиков, пользователей. Следует отметить, что вехи MSF являются точками не «замораживания» проекта (когда одна группа передает результаты своей работы другой группе), а его синхронизации. Все изменения артефактов, полученных в процессе работы над проектом, строго контролируются. Они вносятся не произвольно, а только после согласования на внутренних обзорах. Таким образом обеспечивается возможность принятия решения максимально рано, а «замораживания» проекта — максимально поздно.
Кроме внешних вех, могут быть (и даже рекомендованы) внутренние вехи — события, которые происходят между внешними вехами и свидетельствуют или о достижении какой-либо цели, или о начале и конце какой-либо работы. Внутренние вехи позволяют итеративно создавать итоговые материалы фазы, посредством нескольких обзоров добиваясь нужного качества или содержания.
|
|
Модель команды
Модель, рекомендуемая SDD, предусматривает, что для выполнения проектов необходимо организовать команду специалистов по шести направлениям (ролям):
• управление продуктом;
• управление программой;
• разработка;
• тестирование;
• обучение пользователей;
• сопровождение (логистика).
Исходя из размера проекта определяется, может ли тот или иной член команды совмещать различные роли. В каждую из ролевых групп может входить не более шести человек; при этом один из них назначается руководителем (лидером) группы — он осуществляет руководство и согласование по всем работам, а остальные члены группы являются исполнителями.
Задачи, обязанности (ответственность) и требуемые профессиональные качества каждой роли четко определены, каждому члену группы и группе в целом делегированы достаточные полномочия в сочетании с высокой степенью ответственности.
Каждый исполнитель сам оценивает трудоемкость той части проекта, за которую он отвечает; консолидированная оценка трудоемкости проекта складывается на основе собственных оценок исполнителей, что делает реально достижимыми цели и планы-графики работ.
Работа групп последовательно ориентирована на удовлетворение требований и ожиданий конечных пользователей. Непроизводительные трудозатраты на поддержание формальных и субординационных связей сведены к минимуму.
Модель сравнительно легко масштабируется. Каждый элемент в схеме команды может быть, в свою очередь, циклом.
Таким образом, модель команды MSF очень демократична, поскольку в ней нет явно выделенного центра, строгой иерархической структуры. Модель команды MSF — это команда равных (peer). Схематически ее принято изображать в виде круга, где все роли равноправны и связаны друг с другом.
|
|
Модель приложения
Модель приложения MSF основана на трех основных понятиях.
Многослойное (Multi-tier) приложение — позволяет адекватным образом описать различные аспекты распределенных приложений. Модель приложения MSF выделяет три основных слоя:
• пользовательский интерфейс;
• бизнес-правила;
• управление данными.
Служба (Service) — позволяет описывать логическую структуру приложения в объектно-ориентированном стиле. Служба — это набор взаимосвязанных функций, выполняющих некоторые действия или доставляющих информацию в соответствии со спецификой службы. Функциональность службы доступна только через заранее описанный интерфейс, который скрывает все детали реализации. В рассматриваемой трехслойной модели приложения службы делятся на три категории:
• информационные службы;
• бизнес-службы;
• пользовательские службы.
Логически приложение представляет собой некую сеть служб. Затем логическая модель приложения в форме сети служб транслируется в физическую: все логические службы упаковываются в физические объекты — компоненты, которые реализуются затем в виде программных модулей. Получившаяся в результате такой компоновки архитектура называется физической архитектурой, или архитектурой реализации.
Компонент (Component) — описывает разбиение программного кода на модули, ориентированные на их многократное использование и предоставляющие описанные в спецификации сервисы через опубликованный интерфейс. Компонент представляет собой многократно используемый «черный ящик» и определяется тем, как он взаимодействует с другими компонентами, а не своей внутренней реализацией. Компонент реализует некоторое множество функций системы и имеет формальные и явно описанные интерфейсы.
|
|
Проектирование компонентного ПО
Процесс проектирования MSF состоит из трех стадий.
Первая стадия — концептуальное проектирование — это описание точки зрения пользователя на проект. На этом этапе происходит следующее:
• определение существа проблемы, подлежащей решению, установление цели разработки;
• идентификация основной деятельности: определяются границы области, которую покрывает разрабатываемое решение, причем как перспективные, так и реальные;
• классификация пользователей: группирование пользователей по категориям и описание требований и ожиданий каждой категории;
• составление сценариев «Как есть» и «Как должно быть». Сценарии являются основным выходом стадии концептуального проектирования;
• проверка, оценка и итеративное проектирование. Все стадии проектирования, во-первых, носят итеративный характер, а во-вторых, взаимно перекрываются. Построенный концептуальный проект немедленно подвергается проверке и оценке, результаты которой вызывают очередную итерацию концептуального проектирования, что не мешает начинать и продолжать логическое и физическое проектирование.
Вторая стадия — логическое проектирование — это точка зрения группы проектировщиков на приложение. Логическое проектирование является ядром процесса разработки. Центральной задачей логического проектирования при использовании рекомендуемой MSF модели приложения является вычленение и спецификация служб. Сюда же относятся создание информационной модели, разбиение слишком большой системы на подсистемы и итеративная верификация логического проекта. Результатом логического проектирования является логическая модель приложения, то есть на этой стадии должны быть спроектированы службы, а также специфицированы реализуемые ими функции и интерфейсы.
Третья стадия — физическое проектирование — это точка зрения программистов на приложение. Результатом физического проектирования является физическая архитектура приложения, то есть специфицированы все компоненты приложения. Основное содержание этой стадии — упаковка служб в физические компоненты приложения.
|
|
Планирование архитектуры предприятия
Цель планирования архитектуры предприятия (Enterprise architecture planning) — показать менеджерам предприятия, занимающимся планированием бизнеса, как связаны между собой бизнес-цели и информационные технологии, направленные на поддержку этого бизнеса, а кроме того, как можно использовать фундаментальные модели для планирования развития бизнеса. Без подобного документа, ориентированного на менеджеров высшего уровня, обосновать и утвердить финансовый план внедрения новых информационных технологий весьма и весьма сложно, так как специалисты в области информационных технологий и бизнес-менеджеры «разговаривают на разных языках». Цель данного компонента методологии — нахождение общего языка. В рамках данного обзора мы не предполагаем давать стилевые рекомендации о том, как создавать такого рода документ или иной артефакт, на основании которого менеджмент будет принимать решение, а лишь укажем набор необходимых аспектов, которые рекомендуется включить в документы.
Enterprise в терминологии MSF — это единица организационной структуры, которая имеет самостоятельную бизнес-задачу (mission). Таким образом, речь может идти как о предприятии в целом, так и о его департаментах, отделениях, отделах и т.д.
Модель архитектуры предприятия предполагает наличие архитектуры бизнеса и архитектуры приложений:
• архитектура бизнеса — определяет основную цель бизнеса и бизнес-процессы, необходимые для достижения этой цели. Она описывает, как эти бизнес-процессы выполняются, и определяет возможности для реорганизации, основанной на изменениях рынка, конкурентоспособной позиции и технологических возможностях;
• архитектура приложений (прикладная архитектура) — определяет набор приложений, которые должны поддерживать бизнес-процессы на предприятии, устанавливает приоритеты для автоматизации бизнес-процессов и/или реорганизации уже работающих приложений. Эти приоритеты основываются на целевой бизнес-архитектуре. Прикладная архитектура показывает способ, с помощью которого приложения будут создаваться, чтобы поддерживать бизнес-процессы;
• информационная архитектура — определяет:
- существенные бизнес-объекты (например, заказчики, заказы и т.д.) и отображает их на бизнес-процессы предприятия, то есть определяет их владельцев и пользователей,
- концептуальную модель данных для объектов и их связей,
- текущую информационную топологию (распределение данных по подразделениям или серверам),
- целевую топологию для будущей бизнес-архитектуры;
• технологическая архитектура — определяет текущую технологическую базу предприятия и, основываясь на бизнес-архитектуре и прикладной архитектуре, а также на оценке новых технологий, описывает, какие технологии и как именно будут внедряться на предприятии.
Все эти компоненты зависимы, их следует рассматривать как стратегические цели, на достижение которых должен быть направлен процесс планирования.
