Средства и методы разработки архитектуры 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