Средства и методы разработки архитектуры MSF

Micposoft Solutions Framеwork (MSF) – комплекс средств и методов процесса разработки проекта из скоординированного набора элементов (программно–технических средств, документации, обучения и сопровождения) для удовлетворения производственной архитектуры [15].

Базисом управления проектом построения производственной архитектуры предприятия является база знаний РМBOK, содержащая следующие области знаний:

– управление объемом работ в проекте,

– управление временем,

–управление стоимость,

– управление качеством,

– управление персоналом,

– управление коммуникациями,

– управление закупками и контрактами,

– управление рисками.

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

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

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

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

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

Целью разработки производственной архитектуры есть логически связанный, цельный план работ и скоординированных проектов для преобразования сложившейся структуры ИС и приложений организации в состояние, определенное на основе текущих и перспективных задач и процессов.

Метод MSF компании Microsoft обеспечивает анализ и разработку требований к ПО, а также проектирование проектных решений, основанных на базовых концепциях предприятия и приоритетности архитектуры. Метод включает в себя построение производственной архитектуры, ориентированной на получение бизнеса, и организацию процесса разработки системы для предприятия в условиях, когда архитектура еще не сформирована.

Этот метод включает набор моделей для организации и эффективного создания информационных технологий в бизнесе:

– производственной архитектуры;

– проектной группы;

– процесса разработки ПО;

– управления рисками;

– процесса проектирования;

– приложения.

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

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

Области

применения

Бизнес Информация

Технология

Рис.11.2. Перспективы производственной архитектуры

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

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

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

Информационная перспектива основывается на возможностях организации автоматизировать бизнес–задачи с помощью персональных компьютеров, серверов и др. оборудования; ОС, общесистемных средств и сетевых компонентов; принтеров и другого периферийного оборудования; данных, которые хранятся в БД и документов, таблиц, созданных в процессе работы организации.

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

Модель проектной группы определяет роли, обязанности каждого участника проекта и распределение между ними ответственности. Эта модель служит для формирования эффективной команды и приведения в соответствие содержания проекта с размером группы и квалификацией участников. Члены проектной группы анализируют планы (разработки, тестирования, эксплуатации, мер безопасности и обучения), выявляют взаимосвязи между ними, создают сводный календарный план, в котором предусматриваются версии проекта и проверку их на функциональность на имеющихся ресурсах. Члены группы выполняют определенную роль по оценки состава проектных решений, рисков и ресурсов и корректировки приоритетов.

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

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

Инфраструктура предприятия предназначена для выполнения требований клиентов к структуре выпуска продукции, а также проведения анализа рынков для продажи продуктов и т.п.

Задачи инфраструктуры состоят в следующем:

– привлечение клиентов к созданию приложения;

– связь с корпоративной сетью;

– сохранение данных на разных компьютерах, которые расположены на разных территориях предприятия;

– выдача информации о продукте через компьютерную сеть и т.п.

Соответственно этим задачам проводится:

– согласование информационных технологий с целями бизнеса;

– обоснование изменений и соответствующих затрат для планирования будущих инвестиций;

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

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

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

Формулировка рисков включает рассмотрение условий возникновение рисков и последствий, которые они вызывают. Устанавливаются причинно–следственные связи рисков, проводится приоритезация рисков, составление плана мониторинга рисков и документа с описанием возможных рисков в проекте, в котором определены меры вероятности возникновения риска, схема оценки типа «почти невозможно», «маловероятно», «возможно» и денежные компенсации за предотвращение рисков. В плане графике предусматривается мониторинг рисков – своевременное исполнение превентивных мер для снятия появляющихся угроз риска.

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

Процесс проектирования – это систематический способ от абстрактных концепций к конкретным техническим решениям. На этапе выработки концепции формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение операции определенным пользователем системы. Сценарии разбиваются на последовательность действий – примеров использования (use cases), которые необходимо выполнить пользователю для выполнения операции. Существует три уровня процесса проектирования концептуальный, логический и физический. Процесс проектирования заканчивается описанием функциональных спецификаций.

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

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

Контрольные вопросы и задания

1. Дайте характеристику спецификации компонента.

2. Определите языковые средства описания компонентов.

3. Представьте объекты языка JAVA.

4. Определите методы интеграции объектов языка JAVA.

5. Определите основные характеристики объектов в системе CORBA.

6. Приведите структуру описания спецификации интерфейса в языке IDL.

7. Расскажите об особенностях описания объектов в системе СОМ.

8. Проведите сравнение средств CORBA и СОМ.

9. Для каких целей создано Rational Rose.

10. Назовите инструменты Rational Rose какими Вы пользовались.

11. Дайте перечень диаграмм языка моделирования UML.

12. Определите процесс разработки ПС с помощью UML.

13. Для каких целей разработан метод MSF?.

14. Назовите основные модели MSF.

15. Как решаются вопросы управления проектом и рисками в системе MSF.

16. Цели и задачи проектной группы в MSF.

Литература к теме 11.

1. Crnkovic I., Hinch B., Jonsson T., Kiziltan Z. Specification, Implementation and Deployment of Components // Communications of the ACM.–2002.–vol.45.–№ 10.–P.35–40.

2. Гамма Э, .Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно–ориентированного проектирования. Паттерны проектирования.– СПб:Питер, 2001.–368с.

3. Монсон-Хейфел Р. Enterprise JavaBeans. – СПб: Символ-Плюс, 2002. – 672 с.

4. Барлет Н., Лесли А., Симкин С. Программирование на JAVA. Путеводитель.– Киев.-1996.- 736с.

5. Холл М. Сервлеты и JavaServer Pages. Библиотека программиста. – СПб.: Питер, 2001. – 496 с.

6. Бабенко Л.П., Поляничко С.Л. Модели классификации объектов программной инженерии// Проблемы программирования.–Вып. 1.–С.25–32.

7. Грищенко В.Н., Лаврищева Е.М. Компонентно–ориентированное программирование. Состояние, направления и перспективы развития // Проблемы программирования.–2002.–№ 1–2.–c. 80–90.

8. Орфали Р., Харки Д., Эрварс Д. Основы CORBA .– М: НАЛИП, 1999. – 317с.

9. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510с.

10. Андон Ф.И., Лаврищева Е.М. Методы инженерии распределенных компьютерных систем, Киев, Изд. «Наукова думка», 1997г.–228с.

11. Роджерсон Д. Основы СОМ. Руск..пер.- Microsoft Press.- 361c.

12. Кендалл Скотт. Унифицированный процесс. Основные концепции.–Москва–С–Петербург–Киев.–2002.–157.

13. UML. Специальный выпуск. Питер.–Санкт–Петербург–Москва–Харьков–Минск.–2002. –552с.

14. .Трофимов С.А. CASE-технологии: практическая работа в Rational Rose.– 2–е изд.– М.: Бином–Пресс, 2002.–288с.

15. С.Ф.Уилсон, Б.Мєйлс, Т.Ленгрейв. Принципы проектирования и разработки программного обеспечения. Учебный курс МCSD.–Пер. с анг.–М.: Из–во торговый дом «Русская редакция», 2000.–608с.

ПРИЛОЖЕНИЕ 1