Лекция 2 Семестр 1

1. Схема развития архитектуры ИС (Zachman Framework)

Джон Захман (1987 г.)
1

2.

В 1987 году Джон Захман опубликовал полезную схему развития архитектуры
информационной системы
Схема Захмана (Zachman Framework) рассматривается с целью формирования
взгляда на архитектуру ИС с точки зрения всех участников ее разработки.
.
Схема создает контекст для описания различных представлений архитектуры
разрабатываемой системы. Эти представления соответствуют тому, как видят
систему ее заказчик, проектировщик и разработчик, причем в разрезе
нескольких выбранных аспектов.
2

3.

Схема Захмана
(Пример 1)
3

4.

В схеме Захмана каждой строке соответствует точка зрения какого-либо
участника проекта по созданию системы. Аспекты представлены в схеме
колонками.
Архитектурное представление - это ячейка таблицы, соответствующая
пересечению выбранного столбца и выбранной строки.
Взгляд какого-либо лица - это совокупность ячеек в пределах одной строки
(точки зрения), то есть совокупность архитектурных представлений с выбранной
точки зрения, соответствующая выбранным аспектам системы.
Захман определяет архитектуру как представление конечного продукта (в данном
случае информационной системы) с точки зрения одного из заинтересованных
лиц.
Таким образом, существует не одна архитектура, а некое множество архитектур.
В зависимости от того, кем вы являетесь и на каком аспекте фокусируете
внимание, вы видите архитектуру системы по-разному.
4

5.

5

6.

После того как основные ракурсы проектирования установлены, схема Захмана
раскладывает знания об информационной системе по шести слоям, которые ведут нас
от целей бизнеса, ради которой затевается разработка ИС, к конкретной технологии их
достижения. Чем ниже уровень - тем сильнее зависимость от решений, принятых ранее.
Уровни:
•предметная область - контекст создания
системы, ее границы,
•модель предприятия - бизнес-категории и
связанные с ними бизнес-правила,
•модель системы - логическая модель
архитектуры, данных, функций,
•модель технологии - особенности
физической реализации,
•компоненты - конкретные объекты и
настройки системы,
•функционирующая система и ее свойства.
6

7.

Характеристика взгляда состоит из двух частей:
Описание взгляда, включающее:
· Точку зрения (статус человека, имеющего данный взгляд);
· Что показывает взгляд (аспект);
· Техника или язык, описывающий данный взгляд (например, IDEF1X для аспекта
данных, IDEF0 или диаграмма потока данных для функционального аспекта);
· Уровень детальности (высокий или низкий);
· Предметную область (узкая или широкая);
· Предполагаемое использование (как будет использоваться взгляд);
· Пользователя (кто будет использовать взгляд);
· Граничные предположения (предположения по поводу интеграции этого взгляда с
другими).
Управляющая информация о взгляде:
· Как был разработан взгляд;
· С кем контактировать для управления изменениями;
· Статус (насколько взгляд полон и насколько определен);
· Составные части (например, диаграммы, глоссарии, тенденции, критические для
успеха факторы).

8.

Фрагмент схемы Захмана (точки зрения заказчика)
8

9.

Фрагмент схемы Захмана (точки зрения заказчика и проектировщика)
9

10.

Фрагмент схемы Захмана (точки зрения программиста)
10

11.

Чтобы добраться до модели системы, необходимо сформировать требования двух
предыдущих уровней - предметной области автоматизации и модели работы
предприятия для которого разрабатывается ИС.
Далее, чтобы реализация разработанной модели системы стала возможной,
необходимо проработать технологическую модель и разработать конкретные
компоненты.
Для разработки спецификации требований к ИС необходимо ответить на каждый из
шести универсальных вопросов для каждого из шести слоев.
Разумеется, эта разработка выполняется итеративно и порядок выявления свойств
будущей системы чаще всего не совпадает с последовательностью ячеек в схеме
Захмана. Но важно понимать, что изменения требований в каждом верхнем слое с
большой вероятностью приведут к изменениям в последующих слоях. Может быть и
обратная ситуация - изменения, например, в технологической модели, могут
привести к изменению требований верхнего уровня - бизнес-правил и
функций. Поэтому проведя изменения в одной из ячеек, необходимо оценить их
влияние на все ячейки схемы.
11

12.

Схема Захмана (Пример 2)
12

13.

Схема Захмана (Пример 3)
13

14.

Схема Захмана (Пример 4)
14

15. Общие требования к методологии и технологии проектирования ИС

15

16.

Методологии, технологии и инструментальные средства проектирования (CASEсредства) составляют основу проекта любой ИС.
Методология реализуется через конкретные технологии и поддерживающие их
стандарты, методики и инструментальные средства, которые обеспечивают
выполнение процессов ЖЦ.
Любая технология представляет собой организованную и оформленную в
нормативно – технических и организационно – правовых документов систему
методов, стандартов, правил и приемов выполнения работ, а также
инструментальных средств их автоматизации, обеспечивающую эффективную и
управляемую процедуру получения продукции с заданными свойствами для
заданных или заранее оговоренных условий.
16

17.

Технология проектирования определяется как совокупность трех
составляющих:
пошаговой процедуры, определяющей последовательность технологических
операций проектирования;
критериев и правил, используемых для оценки результатов выполнения
технологических операций;
нотаций (графических и текстовых средств), используемых для описания
проектируемой системы.
17

18.

18

19.

Технология проектирования, разработки и сопровождения ИС должна удовлетворять
следующим общим требованиям:
технология должна поддерживать полный ЖЦ ПО;
технология должна обеспечивать гарантированное достижение целей разработки
ИС с заданным качеством и в установленное время;
технология должна обеспечивать возможность выполнения крупных проектов в
виде подсистем (т.е. возможность декомпозиции проекта на составные части,
разрабатываемые группами исполнителей ограниченной численности с
последующей интеграцией составных частей). Опыт разработки крупных ИС
показывает, что для повышения эффективности работ необходимо разбить проект
на отдельные слабо связанные по данным и функциям подсистемы. Реализация
подсистем должна выполняться отдельными группами специалистов. При этом
необходимо обеспечить координацию ведения общего проекта и исключить
дублирование результатов работ каждой проектной группы, которое может
возникнуть в силу наличия общих данных и функций;
19

20.

технология должна обеспечивать возможность ведения работ по проектированию
отдельных подсистем небольшими группами (3-7 человек). Это обусловлено
принципами управляемости коллектива и повышения производительности за счет
минимизации числа внешних связей;
технология должна обеспечивать минимальное время получения работоспособной
ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных
подсистем. Реализация ИС в целом в короткие сроки может потребовать
привлечения большого числа разработчиков, при этом эффект может оказаться
ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим
числом разработчиков. Практика показывает, что даже при наличии полностью
завершенного проекта, внедрение идет последовательно по отдельным
подсистемам;
20

21.

технология должна предусматривать возможность управления конфигурацией
проекта, ведения версий проекта и его составляющих, возможность
автоматического выпуска проектной документации и синхронизацию ее версий
с версиями проекта;
технология должна обеспечивать независимость выполняемых проектных
решений от средств реализации ИС (систем управления базами данных (СУБД),
операционных систем, языков и систем программирования);
технология должна быть поддержана комплексом согласованных CASE-средств,
обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
21

22.

Реальное применение любой технологии проектирования, разработки и
сопровождения ИС в конкретной организации и конкретном проекте
невозможно без выработки ряда стандартов (правил, соглашений), которые
должны соблюдаться всеми участниками проекта.
К таким стандартам относятся следующие:
стандарт проектирования;
стандарт оформления проектной документации;
стандарт пользовательского интерфейса.
22

23.

Стандарт проектирования должен устанавливать:
набор необходимых моделей (диаграмм) на каждой стадии проектирования и
степень их детализации;
правила фиксации проектных решений на диаграммах, в том числе: правила
именования объектов (включая соглашения по терминологии), набор атрибутов для
всех объектов и правила их заполнения на каждой стадии, правила оформления
диаграмм, включая требования к форме и размерам объектов, и т. д.;
требования к конфигурации рабочих мест разработчиков, включая настройки
операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
механизм обеспечения совместной работы над проектом, в том числе: правила
интеграции подсистем проекта, правила поддержания проекта в одинаковом для
всех разработчиков состоянии (регламент обмена проектной информацией,
механизм фиксации общих объектов и т.д.), правила проверки проектных решений
на непротиворечивость и т. д.
23

24.

Стандарт оформления проектной документации должен устанавливать:
комплектность, состав и структуру документации на каждой стадии
проектирования;
требования к ее оформлению (включая требования к содержанию разделов,
подразделов, пунктов, таблиц и т.д.),
правила подготовки, рассмотрения, согласования и утверждения документации
с указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой в качестве
встроенного средства подготовки документации;
требования к настройке CASE-средств для обеспечения подготовки
документации в соответствии с установленными требованиями.
24

25.

Стандарт интерфейса пользователя должен устанавливать:
правила оформления экранов (шрифты и цветовая палитра), состав и
расположение окон и элементов управления;
правила использования клавиатуры и мыши;
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя
и т.д.
25

26. Этапы разработки ИС Вендров А.М.

26

27.

I. Анализ. Задача формирование требований к системе является одной из наиболее ответственных,
трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Анализ
деятельности организации, выполняемый на данном этапе, должен помочь в формировании
требований к ИС, корректно и точно отражающих цели и задачи организации- заказчика. Наряду с
изучением требований пользователя и имеющихся систем на этапе анализа необходимо создать
информационную модель системы. Здесь же необходимо определить инфологическую модель
данных, входные данные, процессы и предполагаемые выходные данные. Моделирование данных,
выполняемое на данном этапе, включает в себя выявление и описание объектов и их атрибутов, а
также связи между сущностями (описание модели в виде ER-диаграммы). Описание и
документирование всех преобразований данных (процессов) может быть выполнено с помощью
таких средств анализа, как схемы информационных потоков (DFD – data flow diagram) или моделей
функций и процессов.
Конечной целью моделирования бизнес-процессов, протекающих в
организации и реализующих ее цели и задачи является построение моделей организации, описанных
в терминах бизнес-процессов и бизнес-функций. На этом же этапе изучаются имеющееся
оборудование и программные средства. Результатом анализа должно стать лучшее понимание
функционального назначения системы, существующие и потенциальные проблемы, а также сфера ее
действия.
На этом этапе заказчик и проектировщик должны работать сообща.
27

28.

II. Проектирование. Проектировщики в качестве исходной информации получают
результаты анализа. Полученная в результате анализа информационная модель
сначала преобразуется в логическую. Параллельно с проектированием модели данных
выполняется проектирование процессов, чтобы получить описания (спецификации)
всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть
бизнес - логики обычно реализуется в модели данных (ограничения целостности,
триггеры, хранимые процедуры). При проектировании модулей определяют
интерфейсы программ: меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечные продукты этапа проектирования:
- логическая модель данных (на основании ER-модели, разработанной на этапе
анализа);
- набор спецификаций модулей системы (на базе моделей функций).
Также на этапе проектирования определяется:
- выбор платформы и ОС (могут быть не единственными);
- характеристики архитектуры: ф/с или к/с; количество уровней (1, 2 или 3);
централизованная или распределенная БД; однородность или неоднородность БД (по
количеству используемых серверов). Этап проектирования заканчивается
разработкой технического проекта ИС.
28

29.

III. Реализация. На этом этапе осуществляется создание всех компонент ПО
ИС, установка технических средств, разработка эксплуатационной
документации.
29

30.

IV. Этап тестирования обычно оказывается распределенным по времени.
А) после завершения разработки отдельного модуля системы выполняют
автономный тест, который преследует следующие цели:
- обнаружение отказов модуля (жестких сбоев);
- соответствие модуля спецификации (наличие всех необходимых функций и
отсутствие лишних функций).
Б) После того как автономный тест успешно пройден, модуль включается в
состав разработанной части системы и группа сгенерированных модулей
проходит тесты связей, которые должны отследить их взаимное влияние.
30

31.

После тестирования на взаимное влияние модулей необходимо выполнить
еще ряд тестов:
В) тесты на проверку надежности работы:
1) тест имитации отказов, демонстрирующий, насколько хорошо система
восстанавливается после сбоев ПО и отказов аппаратного обеспечения;
2) тест наработки на отказ (устойчивость системы при штатной работе для
оценки времени безотказной работы системы);
3) системный тест (проверка функциональности системы);
4) приемо-сдаточные испытания (такой тест предусматривает показ ИС
заказчику и должен содержать группу тестов, моделирующих реальные
бизнес-процессы, чтобы показать соответствие реализации требованиям
заказчика).
Как правило, тестирование и эксплуатация занимают от 50% до 60% общего
времени разработки ИС.
31

32.

V. Ввод в действие. Эксплуатация и сопровождение. После ввода в
действия организуется обучение конечных пользователей.
Практически сразу после ввода системы в строй конечные пользователи
начинают просить внести в нее изменения. Внесение изменений и
исправлений выполняется службой сопровождения системы, работающей в
трех направлениях:
- корректирующее обслуживание – как ответ на возникающие ошибки
системы;
- адаптивное обслуживание – как ответ на изменение корпоративной среды;
- усовершенствование – расширение возможностей системы.
32