1. Общая характеристика модели приложения
Приложения масштаба предприятия отличаются размером: это большие бизнес-приложения.
— сверхсложные системы
При проектировании и разработке производственных приложений нужно учитывать множество различных требований. Кроме того, каждое решение по одному требованию влияет на другие, причем в таком влиянии непросто разобраться и еще труднее его предсказать. Таким образом, несоблюдение всего одного требования способно «провалить» весь проект.
Как и все современные программы, производственные приложения должны быть достаточно надежными и производительными, а также обладать интуитивно понятным и хорошо организованным пользовательским интерфейсом. Однако, помимо перечисленного, производственным приложениям присущи еще три особенности:
• Сложность — это многопользовательские многокомпонентные приложения, разработанные большим коллективом программистов и предназначенные для обработки огромного количества данных, параллельного выполнения множества процессов и интенсивного
использования распределенных ресурсов. Естественно, что используемые в них алгоритмы очень сложны. Такие приложения, как правило, развертываются на различных платформах, взаимодействуют с другими приложениями и эксплуатируются в течение продолжительного времени.
• Ориентация на бизнес — цель таких приложений — решение конкретных задач бизнеса; они реализуют правила, процессы и объекты, присущие производственным процессам конкретной организации. Именно для этого их разрабатывают, развертывают и эксплуатируют.
• Важность — производственные приложения должны быть достаточно надежными, чтобы выдерживать непрерывную эксплуатацию. От них требуется исключительная гибкость в вопросах, касающихся масштабирования и развертывания, а также наличие средств обслуживания, мониторинга и администрирования. Требования к приложениям постоянно ужесточаются, и это делает разработку производственных приложений еще более трудной. Из-
за постоянной модернизации оборудования и программного обеспечения, а также наличия конкуренции, необходимо, чтобы бизнес-си-стемы быстро реагировали на любые изменения и обладали исключительно высокой производительностью. С ростом требований организациям приходится наращивать долю автоматизированных процессов, быстрее создавать программное обеспечение, справляться с обслуживанием все большего числа пользователей и без задержек обрабатывать огромное количество данных,. Однако сложность технологий, используемых при создании корпоративных решений, и частота их изменения еще больше усложняют разработку. Поэтому при проектировании производственных приложений необходимо тщательно взвесить и сбалансировать множество требований к приложению, включая;
• его бизнес-цели;
• как быстро оно должно быть создано;
• бюджет разработки;
• количество разработчиков, тестеров и сопровождающего персонала;
• поддерживаемое количество пользователей;
• важность производительности и простоты работы с приложением;
• оборудование, на котором оно будет работать;
• где приложение будет развернуто:
• требования к защите данных;
• продолжительность эксплуатации.
Не разобравшись во взаимосвязях между этими сложными и часто конфликтующими требованиями, трудно определить, с чего начать. Поэтому прежде всего нужно выбрать способ разработки приложения и метод организации проектных работ, которые позволят наилучшим образом учесть множество требований.
Архитектура производственных приложений
Один из принципов разработки современных приложений требует предварительного определения архитектуры, на основе которой создается система.
«архитектура приложения» — набор основополагающих проектных решений относительно
организации программной системы. К. ним относятся:
• выбор структурных элементов и интерфейсов, образующих систему;
• поведение системы, определяемое взаимодействием этих элементов;
• объединение структурных и поведенческих элементов в более
крупные подсистемы;
• стиль организации системы.
Архитектурный стиль характеризует семейство систем с помощью структурной модели.
В архитектурный стиль входят:
• словарь типов компонентов;
• набор ограничений, определяющий их объединение;
• одна или несколько семантических моделей, позволяющих определить свойства системы по свойствам ее частей,
К концепции архитектуры, разработанной Бучем и Шоу, можно добавить выделенные Бучем характеристики удачного архитектурного решения:
• гибкость;
• простота;
• реализуемость;
• четкое разграничение проблем;
• сбалансированное распределение ответственности;
• сбалансированность экономических и технологических ограничений.
Несомненно, постоянное обновление технологии, быстрый рост
новые проблемы и изменяют приоритеты разработчиков архитектур приложений.
В этом разделе мы расскажем об этих трудностях и способах их устра-
нения.
- 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)Организованные риски;
- Этап «Выпуск продукта» и его результаты