Перспективы производственной архитектуры
Данная модель является структурной, включает четыре перспективы: бизнес, приложение, информацию и технологию (рис.11.2).
Области
применения
 |
 |
Технология
Рис.11.2. Перспективы производственной архитектуры
Рассматриваемая модель состоит из четырех перспектив: бизнеса, приложения, информации и технологии, которые связаны между собой разными зависимостями и взаимодействиями. Основной задачей этой модели является приспособление производственной архитектуры к бизнес–целям организации путем итерационного, поэтапного выпуска серии последовательных версий, ориентированных на указанные приоритеты, выполнение отдельных проектов для постепенного решения задач и последовательной корректировки производственной архитектуры.
Бизнес–перспектива включает стратегии и планы перехода к лучшему состоянию предприятия, а именно глобальные цели и задачи организации; виды продуктов и услуг организации; бизнес–процессы реализации основных функций организации и связи между ними.
Прикладная перспектива (приложение) включает услуги и сервисы, информацию и функции, которые требуются для связи пользователей, в том числе описание сервисов поддержки процессов в бизнес–перспективе; описание взаимодействий и зависимостей корпоративных приложений; совершенствование существующих и развитие новых приложений бизнес–перспективы.
Информационная перспектива основывается на возможностях организации автоматизировать бизнес–задачи с помощью персональных компьютеров, серверов и др. оборудования; ОС, общесистемных средств и сетевых компонентов; принтеров и другого периферийного оборудования; данных, которые хранятся в БД и документов, таблиц, созданных в процессе работы организации.
Технологическая перспектива включает технологию работы с аппаратным и программным обеспечением для регламентации действий разработчиков по созданию производственной архитектуры в рамках имеющейся среды разработки. Эта перспектива направлена на логическое описание инфраструктуры и системных компонентов, которые необходимы для поддержки прикладной и информационной перспектив (топологии, среды разработки, средств защиты), а также на определение перечня технологических стандартов и сервисов для выполнения задач организации.
Модель проектной группы определяет роли, обязанности каждого участника проекта и распределение между ними ответственности. Эта модель служит для формирования эффективной команды и приведения в соответствие содержания проекта с размером группы и квалификацией участников. Члены проектной группы анализируют планы (разработки, тестирования, эксплуатации, мер безопасности и обучения), выявляют взаимосвязи между ними, создают сводный календарный план, в котором предусматриваются версии проекта и проверку их на функциональность на имеющихся ресурсах. Члены группы выполняют определенную роль по оценки состава проектных решений, рисков и ресурсов и корректировки приоритетов.
Модель процесса разработки ПО определяет организационную структуру процесса и руководство им в течение всего времени жизни проекта. Отличительные особенности модели – поэтапность, итеративность и гибкость. Модель определяет фазы, этапы, виды деятельности и результаты процесса разработки приложения и их связь с моделью проектной группы. Использование этой модели обеспечивает контроль за ходом разработки проекта, минимизацию рисков, повышение качества и сокращение сроков выполнения проекта.
На этапе разработки создаются: код приложения, скрипты установки и конфигурации, окончательная функциональная спецификация, спецификации и сценарии тестирования. Все эти работы выполняют члены проектной группы. Они создают инфраструктуру и документ на конфигурацию.
Инфраструктура предприятия предназначена для выполнения требований клиентов к структуре выпуска продукции, а также проведения анализа рынков для продажи продуктов и т.п.
Задачи инфраструктуры состоят в следующем:
– привлечение клиентов к созданию приложения;
– связь с корпоративной сетью;
– сохранение данных на разных компьютерах, которые расположены на разных территориях предприятия;
– выдача информации о продукте через компьютерную сеть и т.п.
Соответственно этим задачам проводится:
– согласование информационных технологий с целями бизнеса;
– обоснование изменений и соответствующих затрат для планирования будущих инвестиций;
– усовершенствование внутренних и внешних связей между подразделениями для повышения эффективности работы с заказчиками, поставщиками и партнерами и т.п..
Модель управления рисками предназначена для управления рисками проекта. Она определяет порядок и условия реализации упреждающих решений и мер для постоянного выявления наиболее существенных моментов риска и реализации стратегии их устранения. Использование этой модели и ее основных принципов помогает команде сосредоточиться на наиболее важных моментах разработки ПО. Модель управления рисками является основой выявления, планирования и мониторинга рисков.
Выявление состоит в анализе и формулировке имеющихся рисков, причиной которых могут быть неучтенные особенности проекта и среды, в которой будет разрабатываться проект. Выявленные риски классифицируются и составляется база знаний о рисках на уровне предприятия.
Формулировка рисков включает рассмотрение условий возникновение рисков и последствий, которые они вызывают. Устанавливаются причинно–следственные связи рисков, проводится приоритезация рисков, составление плана мониторинга рисков и документа с описанием возможных рисков в проекте, в котором определены меры вероятности возникновения риска, схема оценки типа «почти невозможно», «маловероятно», «возможно» и денежные компенсации за предотвращение рисков.
В плане графике предусматривается мониторинг рисков – своевременное исполнение превентивных мер для снятия появляющихся угроз риска.
Модель процесса проектирования определяет цели и задачи процесса разработки производственной архитектуры с параллельным и итерационным выполнением отдельных работ. Процесс включает три основные фазы разработки – концептуальное, логическое и физическое проектирование. Переход от концептуального проекта к физическому способствует превращению созданного набора сценариев в совокупность компонентов и сервисов, образующих приложение и реализующих требования заказчика и пользователей.
Процесс проектирования – это систематический способ от абстрактных концепций к конкретным техническим решениям. На этапе выработки концепции формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение операции определенным пользователем системы. Сценарии разбиваются на последовательность действий – примеров использования (use cases), которые необходимо выполнить пользователю для выполнения операции. Существует три уровня процесса проектирования концептуальный, логический и физический. Процесс проектирования заканчивается описанием функциональных спецификаций.
Модель приложения определяет трехуровневую структуру и сценарный метод проектирования и разработки приложения. Применение этой модели обеспечивает наглядность разработки, параллельное выполнение работ на процессах и различные удобства при эксплуатации и развертывании компонентов приложения на компьютерах и в различных серверах.
Таким образом, методология MSF обеспечивает проектирование приложения для предприятия с помощью приведенных принципов, моделей и методов решения задач этого предприятия.
