Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
3_Вимоги_1 / 09.10.12 / 3_Обзор методол / 1_Обзор методологий.doc
Скачиваний:
106
Добавлен:
08.06.2015
Размер:
567.81 Кб
Скачать

Проектирование компонентного по

Процесс проектирования MSF состоит из трех стадий.

Первая стадия — концептуальное проектирование — это описание точки зрения пользователя на проект. На этом этапе происходит следующее:

• определение существа проблемы, подлежащей решению, установление цели разработки;

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

• классификация пользователей: группирование пользователей по категориям и описание требований и ожиданий каждой категории;

• составление сценариев «Как есть» и «Как должно быть». Сценарии являются основным выходом стадии концептуального проектирования;

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

Вторая стадия — логическое проектирование — это точка зрения группы проектировщиков на приложение. Логическое проектирование является ядром процесса разработки. Центральной задачей логического проектирования при использовании рекомендуемой MSF модели приложения является вычленение и спецификация служб. Сюда же относятся создание информационной модели, разбиение слишком большой системы на подсистемы и итеративная верификация логического проекта. Результатом логического проектирования является логическая модель приложения, то есть на этой стадии должны быть спроектированы службы, а также специфицированы реализуемые ими функции и интерфейсы.

Третья стадия — физическое проектирование — это точка зрения программистов на приложение. Результатом физического проектирования является физическая архитектура приложения, то есть специфицированы все компоненты приложения. Основное содержание этой стадии — упаковка служб в физические компоненты приложения.

Планирование архитектуры предприятия

Цель планирования архитектуры предприятия (Enterprise architecture planning) — показать менеджерам предприятия, занимающимся планированием бизнеса, как связаны между собой бизнес-цели и информационные технологии, направленные на поддержку этого бизнеса, а кроме того, как можно использовать фундаментальные модели для планирования развития бизнеса. Без подобного документа, ориентированного на менеджеров высшего уровня, обосновать и утвердить финансовый план внедрения новых информационных технологий весьма и весьма сложно, так как специалисты в области информационных технологий и бизнес-менеджеры «разговаривают на разных языках». Цель данного компонента методологии — нахождение общего языка. В рамках данного обзора мы не предполагаем давать стилевые рекомендации о том, как создавать такого рода документ или иной артефакт, на основании которого менеджмент будет принимать решение, а лишь укажем набор необходимых аспектов, которые рекомендуется включить в документы.

Enterprise в терминологии MSF — это единица организационной структуры, которая имеет самостоятельную бизнес-задачу (mission). Таким образом, речь может идти как о предприятии в целом, так и о его департаментах, отделениях, отделах и т.д.

Модель архитектуры предприятия предполагает наличие архитектуры бизнеса и архитектуры приложений:

• архитектура бизнеса — определяет основную цель бизнеса и бизнес-процессы, необходимые для достижения этой цели. Она описывает, как эти бизнес-процессы выполняются, и определяет возможности для реорганизации, основанной на изменениях рынка, конкурентоспособной позиции и технологических возможностях;

• архитектура приложений (прикладная архитектура) — определяет набор приложений, которые должны поддерживать бизнес-процессы на предприятии, устанавливает приоритеты для автоматизации бизнес-процессов и/или реорганизации уже работающих приложений. Эти приоритеты основываются на целевой бизнес-архитектуре. Прикладная архитектура показывает способ, с помощью которого приложения будут создаваться, чтобы поддерживать бизнес-процессы;

• информационная архитектура — определяет:

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

- концептуальную модель данных для объектов и их связей,

- текущую информационную топологию (распределение данных по подразделениям или серверам),

- целевую топологию для будущей бизнес-архитектуры;

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

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

.

Соседние файлы в папке 3_Обзор методол