- •Оглавление
- •1 Жизненный цикл информационной системы. Гост 51 904
- •2 Модели жизненного цикла информационной системы. Гост 15 271
- •3 Методологии проектирования. Каноническое проектирование. Гост 34.601-90
- •4 Методологии проектирования. Типовое проектирование.
- •5 Процессы жизненного цикла информационной системы. Гост 12 207
- •6 Процессы жизненного цикла информационной системы. Процессы планирования
- •7 Процессы жизненного цикла информационной системы. Процессы определений требований к ис.
- •8 Процессы жизненного цикла информационной системы. Процессы проектирования.
- •9 Процессы жизненного цикла информационных систем. Процессы кодирования.
- •10 Процессы жизненного цикла информационных систем. Процессы интеграции.
- •11 Процессы планирования. Планирование инфраструктуры проекта.
- •12 Процессы планирования. Планирование ресурсов проекта.
- •13 Стратегии и методы проектирования информационных систем
- •14 Анализ объекта автоматизации. Методологии анализа.
- •15 Анализ объекта автоматизации. Инструментальные средства поддержки процессов анализа.
- •16 Процессы проектирования. Проектирование системной архитектуры.
- •17 Процессы проектирования. Методики описания системной архитектуры.
- •Ieee 1471
- •18 Процессы проектирования. Архитектурные стили и шаблоны проектирования.
- •19 Процессы проектирования. Проектирование информационной архитектуры.
- •20 Процессы проектирования. Построение er модели. Виды нотации
- •21 Процессы проектирования. Построение логической модели данных.
- •22 Процессы проектирования. Построение физической модели данных.
- •23 Процессы проектирования. Шаблоны информационной архитектуры.
- •24 Процессы проектирования. Проектирование программной архитектуры.
- •25 Процессы проектирования. Модели описания программной архитектуры.
- •26 Процессы проектирования. Шаблоны программной архитектуры.
- •27 Процессы проектирования. Проектирование инфраструктуры.
- •28 Процессы проектирования. Проектирование интерфейсов
15 Анализ объекта автоматизации. Инструментальные средства поддержки процессов анализа.
Ramus (idef0, dfd);
visual paradigm (UML),
bpwin (bpwin -> AllFusion Process Modeler -> CA ERwin Data Modeler) [idef0, dfd, idef3],
aris (eEPC, ERM, UML).
(не очень понятно, что хотят в билете =\)
На последней лекции ИРВ упоминал ARIS Express (возможно, что-то ещё, но у меня записана только она). Видимо, в билете нужно рассказать про программы, которые позволяют рисовать диаграммы.
ARIS Express – бесплатная версия программы ARIS, позволяющая создавать и редактировать модели.
Бесплатная версия программы поддерживает только базовые типы диаграмм, не имеет многопользовательской поддержки, не использует базу данных, не содержит инструментов для формирования отчётов и средств анализа модели. И самое главное: ARIS Express не поддерживает связи между создаваемыми объектами, в отличие от полноценной платной версии, то есть отсутствует контроль целостности и непротиворечивости модели. Это означает, что при редактировании одной модели программа не будет вносить соответствующие изменения в другую модель, а также не будет проверять, существуют ли должности, указываемые в качестве ответственных в процессе и т.д.
ARIS Express поддерживает следующие типы моделей:
Организационная диаграмма(Organizational chart)
Бизнес-процесс(Business process)
ИТ-инфраструктура(IT infrastructure)
Карта процессов(Process landscape)
Модель данных(Data model)
Карта систем(System landscape)
Доска(Whiteboard)
BPMN диаграмма версии 2.0 (BPMN diagram)
Общие диаграммы(General diagram)
16 Процессы проектирования. Проектирование системной архитектуры.
Эскизное проектирование - операция проектирования системной архитектуры.
Системная архитектура или общая архитектура системы указывает состав технических объектов, программных средств, ручных операций; указываются требования системы между объектами.
Должны быть определены объекты конфигурации технических и программных средств. Компоненты должны быть разделены на модули, системы, подсистемы и т.д. Необходимо документально оформить привязку системных элементов архитектуры к требованиям системы.
Системная архитектура должна быть оценена с помощью критериев:
Учет требований к системе
Соответствие требованиям к системе
Соответствие стандартам и методам проектирования
Возможность программных объектов выполнять установленные для них требования
Возможность эксплуатации и сопровождения
17 Процессы проектирования. Методики описания системной архитектуры.
Ieee 1471
IEEE 1471 - «Рекомендуемые методы описания архитектуры программных систем». В нем излагается концепция отношений между архитектурой, описанием архитектуры, заинтересованными сторонами, соображениями, точками зрений (разрезами), представлениями и моделями, а также подход к работе с ними.
Можно описать, как статическое представление системы, которое включает в себя архитектуру системы, архитектуру данных, способы хранения, архитектуру оборудования, так и динамическое представление системы – переходы между состояниями системы и передачу данных между частями системы.
В рамках стандарта формализуются точки зрения на архитектуру системы. Для каждой точки зрения прописаны:
Описание;
Назначения;
Графические модели;
Риски, которые нужно учитывать с этой точки зрения.
Пример:
Функциональная точка зрения:
Необходима для описания функциональности ИС, описывает субъекты и их роль, описывает БП, функции пользователей;
Использует Use Case UML;
Риски: сложность автоматизации функциональности, реализуемость и тестируемость функциональности.
Другие точки зрения:
Сценарная точка зрения (динамическое представление ИС);
Концептуальная точка зрения (основная структура ИС);
Поведенческая точка зрения;
Логическая;
Информационная;
Точка зрения размещения (связь компонентов ИС с техническими объектами);
Технологическая точка зрения (формализованное использование технологий, средств разработки, готовых модулей).
(См подробное описание - ссылка)
Модель Захмана
Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив или структур для описания современных сложных корпоративных систем. Дж. Захман определил архитектуру предприятия как "набор описательных моделей, которые применимы для описания предприятия в соответствии с требованиями управленческого персонала и которые могут развиваться в течение определенного периода". Термин "архитектура" здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта - предприятия, и сложного искусственного объекта, такого как здание или космическая станция.
Для удобства описания Захман предложил т.н. модель архитектуры предприятия. Модель преследует две основные цели - с одной стороны, логически разбить все описание архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой - обеспечить возможность рассмотрения целостной архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов (шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом).
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес (продукты, услуги, клиенты), а также формулируется бизнес-стратегия. Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения системного архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне бизнес-функций
На четвертом уровне - технологической или физической модели - осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Шестой уровень описывает работающую систему. На этом уровне могут быть введены такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk и т.д. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При развитии модели отмечены возможности рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.
Основные характеристики данной модели:
простота для понимания как техническими, так и нетехническими специалистами;
целостность в отношении предприятия;
поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;
возможность применения для планирования, позволяющего лучше принимать решения;
применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия предприятия как целого;
независимость от конкретных инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.
(подробнее - ссылка)
TOGAF
Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.
В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML.
Общая структура:
В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:
Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
Фаза B: разработка бизнес-архитектуры предприятия.
Фаза C: разработка архитектуры данных и архитектуры приложений.
Фаза D: разработка технологической архитектуры.
Фаза E: проверка возможности реализации предложенных решений.
Фаза F: планирование перехода к новой системе.
Фаза G: формирование системы управления преобразованиями.
Фаза H: управление изменением архитектуры.
Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:
Описание существующей технологической архитектуры.
Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
Формирование целевой технологической архитектуры.
Описание существующей системы в терминах TOGAF.
Определение перспектив (представлений) архитектуры.
Формирование модели целевой архитектуры.
Определение ИТ-служб (сервисов).
Подтверждение учета бизнес-требований.
Определение архитектуры и используемых блоков (шаблонов).
Проведение анализа расхождений (gap analysis).
(подробнее - ссылка– 7 и 8 страницы)