2.3.Стадия физического проектирования
это процесс описания компонентов,сервисов и технологий, используемых для получения решения.
Его цель — сопоставить логический проект с рамками существующих технологий, изучить возможности реализации проекта и производительность приложения.
Результат этого этапа проектирования — набор компонентов, проект пользовательского интерфейса для определенной платформы и физический проект базы данных.
Задачи: на стадии физического проектирования проектная группа:
• классифицирует требования и полностью разъясняет их разработчикам;
• связывает логический проект и его реализацию, описывая решение в терминах реализации;
• оценивает разные варианты реализации;
• создает гибкий проект на основе сервисов;
• добивается совместимости с производственной архитектурой;
• проверяет соответствие логического проекта схемам использования и сценариям.
Физический проект — это основа функциональных спецификаций, которые необходимы для контроля качества. Он очень важен, так как предоставляет разработчикам последний шанс проверить проект до написания кода. Когда код уже создается, вносить изменения в проект, конечно, все еше можно, но при этом значительно возрастают затраты.
Физическое проектирование завершается в тот момент, когда собрано достаточно информации для начала разработки или развертывания. Поэтому эти процессы начинаются до завершения физического проектирования; более того, физическое проектирование может продолжаться и в начале стадии «Разработка», что дает дополнительные преимущества в «очистке» проекта. Единственное условие — окончательный проект должен быть утвержден до стабилизации решения.
Стадия физического проектирования в модели MSF состоит из четырех этапов:
исследования, анализа, рационализации и реализации,
Каждый этап заканчивается конкретными результатами; единственное исключение — этап реализации, результаты которого входят в окончательный физический проект,
На стадии исследования:
• определяются физические ограничения инфраструктуры;
• определяются физические требования к решению;
• изучаются риски, возникающие в результате конфликта между
требованиями и физическими ограничениями.
На стадии анализа:
• выбираются возможные технологии реализации;
• создается эскиз модели развертывания, включающий сетевые и
компонентные технологии, а также технологии данных.
На стадии рационализации:
• определяется способ комплектации и развертывания;
• выполняется декомпозиция объектов на компоненты и сервисы;
• компоненты распределяются в соответствии с топологией;
• происходит «очистка» плана комплектации и развертывания.
На стадии реализации:
• выбирается программная модель;
• определяется интерфейс компонентов;
• компоненты описываются на языке разработки;
• изучается структура компонентов.
Результат исследования, анализа, рационализации и реализации —
базовый физический проект, включающий основные спецификации.
Шаг 1: исследование
Цель исследования:
• выявить физические ограничения инфраструктуры и условий, в которых будет эксплуатироваться приложение;
• по возможности избежать рисков, связанных с конфликтом между ограничениями и условиями работы.
К этому этапу разработки уже должны быть известны требования, предъявляемые к приложению, — сколько людей с ним будут работать, сколько транзакций в день оно будет обслуживать и т. д.
Текущая физическая инфраструктура исследуется с помощью топологий — карт, отражающих различные ее особенности. При планировании приложения на физическом уровне иногда полезна топология сети, данных и компонентов . Топология инфраструктуры, созданная на этапе исследования, отражает ее текущее состояние. Далее нужно изучить риски, возникающие из-за конфликтов или расхождений трех топологий.
Стадия исследования завершена, когда выполнены следующие задачи:
• выявлены ограничения и условия работы;
• определены топологии сети,данных и компонентов, а также физические требования приложения;
• изучены риски, возникающие при конфликтах и недостающих элементах в ограничениях и требованиях;
• риски оценены и составлен план их сокращения.
Шаг 2: анализ
Главная цель этой стадии — выбрать технологии для реализации, основываясь на требованиях к приложению.
При анализе технологий в первую очередь изучают вопросы бизнеса, затем вопросы промышленной архитектуры и, наконец, сами технологии.
К вопросам бизнеса относятся:
• возможности — действительно ли данная технология удовлетворяет потребностям бизнеса;
• стоимость продукта — полная стоимость продукта ;
• квалификация пользователей;
• модернизация существующего продукта или разработка нового -важно принимать решения, основываясь на информации о рисках;
• сопровождение .
К вопросам производственной архитектуры относятся:
• соответствие целям архитектуры — приложение должно учитывать цели и принципы архитектуры. Все его задачи основаны на четырех моделях архитектуры: бизнеса, приложения, информации и технологии;
• строгое соответствие архитектуре — архитектура предприятия определяет планы для текущего и будущего состояния системы. Приложение должно соответствовать моделям приложения, информации и технологии архитектуры предприятия;
• возможности роста — масштабируемость приложения следует рассматривать как с точки зрения положения на рынке, так и с точки зрения увеличения сегмента рынка, занятого данным продуктом. При этом, возможно, разрастется и сама компания;
• взаимодействие — приложение должно быть совместимо с другими информационными системами организации. Не мешать работе других систем недостаточно — должен быть определен коммуникационный интерфейс, посредством которого новое приложение могло бы взаимодействовать с другими приложениями.
К технологическим вопросам относятся:
• языки программирования — выбирая язык для разработки компонентов, рассмотрите разные варианты для разных задач проекта, выясните, поддерживает ли язык программирования реализацию взаимосвязанных компонентов, которые при необходимости придется заменять и обновлять;
• стандарты взаимодействия компонентов — платформы и стандарты взаимодействия связаны друг с другом. Выбирая стандарт взаимодействия , изучите возможности кросс-платформенной интеграции с точки зрения производительности приложения. На этом этапе стоит рассмотреть несколько технологий;
• методы доступа к данным — выбирая способ взаимодействия компонентов с хранилищами данных, изучите особенности производительности, стандартизации и перспектив метода.
• системные сервисы — поддерживают инфраструктуру для распределенного решения. Выявите типы сервисов, необходимых для построения решения, и определите, какие из них обеспечиваются штатными системными средствами;
• операционные системы — обратите внимание на сервисы операционной системы — их использование может значительно упростить разработку приложения. Кроме того, операционная система должна обладать достаточным уровнем защиты и масштабируемости;но не забывайте, что в разных операционных системах — разные
методы доступа к их сервисам,
Стадия анализа завершена, когда решены следующие задачи:
• составлен список используемых технологий;
• создана предварительная модель развертывания, включающая предполагаемую топологии сети, данных и компонентов.
Шаг 3: рационализация
Задачи стадии рационализации — интерактивные и итерационные. В некоторых случаях имеет смысл начать с составления модели компонентов, но иногда стоит прежде изучить комплектацию.
начните с той задачи, которая кажется вам самой сложной и наиболее важной.
Определяя стратегию комплектации и развертывания, придерживайтесь трех основных принципов. Во-первых, изучите разные способы комплектации и их обоснования или причины, по которым следует выбрать какую-то конкретную стратегию.
Это может быть:• тип сервиса;• масштабируемость;• производительность:• управляемость;• возможность повторного использования;• бизнес-контекст;
• степень детализации.
Во-вторых, согласуйте стратегию с моделью программирования.
Этот процесс — интерактивный, так как на данном этапе модель программирования еще не ясна.
В-третьих, выявите возможные изменения проекта, способные повлиять на стратегию; при этом учтите причины, изученные на первой стадии создания этой стратегии.
Стадия рационализации завершается, когда решены следующие задачи:
• определена стратегия комплектации и развертывания;
• в рамках создания компонентной модели объекты преобразованы в компоненты, основанные на сервисах,
• с целью создания окончательной модели развертывания, включающей топологии сети, данных и компонентов, компоненты распределены по топологии;
• уточнены модели комплектации и развертывания.
Шаг 4: реализация
На последнем этапе физического проектирования — этапе реализации
• проектная группа создает модель программирования для разработчиков, а также интерфейсы и внутреннюю структуру компонентов.
Модель программирования:
• описывает способы использования выбранных технологий;
• учитывает некоторые особенности спецификаций компонентов, что помогает в дальнейшем согласованно работать над проектом;
• конкретизирует различные элементы решения.
При разработке программной модели следует учесть многие вопросы .
Этап реализации завершается, когда решены следующие задачи:
• выбрана программная модель;
• определены внешние структуры компонентов, в том числе интерфейсы, атрибуты и сервисы;
• определены внутренние структуры компонентов.////////баланс компромисного треугольника
- 2. Модель па
- 2.1.Бизнес - перспектива
- 2.2.Прикладная перспектива
- 2.3.Информационная перспектива
- 2.4.Технологическая перспектива
- 2.5 Основные опасности при разработке производственной архитектуры
- 2.6 Задачи модели производственной архитектуры msf
- 3. Создание производственной архитектуры
- 1. Общая характеристика модели приложения
- 1.1.Повторное использование компонентов
- 1.2.Размер приложения
- 1.3. Производительность приложения
- 1.4.Масштабируемость приложений
- 1.5.Виды архитектуры
- 2. Модель приложений
- 2.1. Бизнес-модель
- 2.2 Пользовательская модель
- 2.3 Логическая модель
- 2.4 Технологическая модель
- 2.5 Модель разработки
- 2.6 Физическая модель
- 1. Общие характеристики модели проектных групп
- 2. Обязанности членов группы
- 3. Модель проектой группы
- 3.1. Менеджер продукта
- 3.2Менеджер программы
- 3.3.Разработчик
- 3.4 Тестер
- 3.5.Инструктор
- 3.6 .Логистик
- 4.Размер групп и масштаб проекта
- 5. Создание группы
- 5.1.Поиск руководителей
- 5.2.Повышение эффективности коллективной работы
- 5.3. Координация работы с внешними группами
- 1. Модель разработки приложений
- 2.Модель процесса разработки msf
- Основные этапы
- Промежуточные этапы
- Итеративность
- 3. Фазы разработки и их основные этапы.
- 3.1 Фаза Анализ
- 3.3.Фаза «Планирование»
- 3.3.Фаза «Разработка»
- 3.4. Фаза «Стабилизация»
- 4. Принципы модели процесса разработки
- 5.Роли членов группы в модели процесса разработки
- Динамика фазы Анализ модели процесса разработки msf
- 1.Процесс исследования
- 1.1.Распределение обязанностей ролей
- 2. Модель управление рисками
- 2.1.Источники риска
- 2.2.Способы управления рисками
- 3.Этап «Одобрение концепции» и его результаты
- 3.1Концепция
- 3.2.Прототип
- 3.3. Структура проекта
- 3.4. Сводный документ оценки рисков
- 3.5. Согласование концепции
- Динамика фазы планирования
- 1.Общая характеристика фазы планирования
- Фаза «Планирование» и процесс проектирования
- Распределение ролей при планировании
- Обязанности ролей при планировании
- 12.Процесс проектирования
- 2.1. Стадии концептуального проектирования
- 2.2.Стадия логического проектирования
- 2.3.Стадия физического проектирования
- 2.1. Управление рисками на фазе планирования
- 4.Этап «Одобрение плана проекта» и его результаты
- 4.1.Функциональные спецификации
- 4.2.Основной план проекта
- 4.2.Основной график проекта
- 4.3.Пересмотренный документ оценки рисков
- Динамика фазы разработки и ее основные результаты.
- 1. Общая характеристика фазы разработки
- 2. Основные этапы разработки
- 2.1.Распределение обязанностей на стадии разработки
- 2.3.Первый этап: анализ и рационализация
- 2.4.Второй этап: реализация
- 2.5.Третий этап: аттестация
- 2.6.Управление рисками
- 3.Этап «Завершение разработки» и его результаты
- 3.1. Код и исполняемые модули
- 3.2.Средства повышения эффективности работы пользователей и сопроводительные материалы
- 3.3. Тестовые материалы
- Динамика фазы стабилизации
- Распределение обязанностей в группе
- Промежуточные этапы
- Управление рисками на фазе Стабилизации
- 1)Организованные риски;
- Этап «Выпуск продукта» и его результаты