Заметим, что привычные нотации формальных моделей (функционально-ориентированных и объектно-ориентированных) подчас слишком рано ведут к неоправданно низкому уровню моделирования.
Модели предметной (проблемной) области рассматривают с позиции категорий участников процесса проектирования систем, к которым относятся пользователи (заказчики), проектировщики (консультанты), участвующие в процессе получения и формирования знаний о проблемной области и формулирующие требования к информационной системе; разработчики и эксплуатационщики информационной системы (ИС). Проектировщики совместно с заказчиками должны формировать модели проблемной области, отражающие содержательную сторону функционирования системы, при этом проектировщики закладывают технологические требования к реализации системы, скрытые от взгляда пользователей. На основе моделей требований разработчики ИС проводят технологическую детализацию проекта и его последующую реализацию. На основе сформированной рабочей документации и полученного конечного продукта системы пользователи - эксплуатационщики осуществляют поддержку функционирования системы в новых условиях. Данный подход нашел воплощение в архитектурах предложенных Д.А. Захманом [7]. В соответствии с этим подходом совокупность моделей определяет одну из архитектур системы (раздел обеспечения системы). В процессе осуществления проекта каждая точка зрения проходит определенное развитие в соответствии с выполняемым этапом проектирования.
Схема (матрица) согласованных архитектур служит простым, но достаточно мощным инструментом по применению системного подхода для планирования работ по созданию и использованию автоматизированных систем, информационных систем и стыковки этих работ.
3.2.1. Основные аспекты построения архитектур
Архитектуры представляют систему с позиции одних и тех же аспектов, но под разными углами зрения. В качестве основных аспектов построения архитектур предлагается рассматривать следующие аспекты:
─ цели, бизнес-правила (мотивация того, почему функционирует система);
─ участники процесса (кто осуществляет процесс);
─ функции (как осуществляется преобразование в системе);
─ объекты – данные (что проходит процесс преобразования);
─ место (где осуществляется процесс);
─ время (графики событий, временные требования к выполнению процесса).
Виды моделей и их отображение в различных архитектурах показаны в таблице
3.1.
Столбцы таблицы фактически отражают разделы обеспечения системы: информационное обеспечение (данные), функциональное обеспечение (функции), коммуникационное обеспечение (сеть), организационное обеспечение и т.д.
Строки таблицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления:
· бизнес среда системы,
· концептуальная модель,
· логическая модель,
· технологическая, «физическая модель»,
· детальная реализация (часто поблочная),
· представление пользователя (эксплуатация).
Таблица 3.1. Матрица согласованных моделей в архитектурах.
| Виды моделей и их реализация | Цели (почему?) Дерево целей | Люди (кто?) Архитек-тура орган-изации | Функции (как?) Архитек-тура прило-жений | Объекты--данные (что?) Архитек- тура данных | Коммуникации (где?) Архитек- тура техноло-гическая | Время (когда?) | |
| 1 | Укрупненная модель организации (планировщик, пользователь) | Список целей и задач | Список организа-ций (подразде-лений) | Список процессов | Список сущностей | Список узлов | Список основных событий |
| 2 | Корпоративная модель организации (пользователь) | Стратеги-ческая модель: цель – стратегия. | Структур-ные модели: подразде-ления – работа | Функци-ональные модели: процесс – ресурс. | Информаци-онно-логические модели: ER-диаг-раммы | Модель топологии узлов | Модель корпора-тивных событий |
| 3 | Системная модель ИС (консультант-проекти-ровщик) | Критерии достиже-ния целей | Роли персонала | Диаграм-мы потоков данных | Логическая модель данных | Логическая модель сетей организации | Модель системных событий |
| 4 | Технологическая модель (разработчик ИС) | Модель «состояние-действие» | Модель интер-фейса | Модель приложе- ний | Модель внутреннего представ- ления | Физическая модель комму-никаций | Модель технических событий |
| 5 | Компоненты (разработчик ИС, субподрядчик) | Шаг/задача | Пользо-ватель – транзакция | Програм- мные модули | Базы данных | Протоколы | Компонент-ные события |
| 6 | Функциони-рующая система (эксплуата-ционщики) | Варианты исполнения | Сеансы работы | Проце- дуры | Ограниче- ния целост- ности | Клиент – сервер | Операцион-ные события |
3.2.2. Участники проекта.
Организация работ по проектированию определяется порядком взаимодействия между всеми сторонами-участниками. Так при проектировании информационной системы (ИС) участниками процесса являются: инициатор проекта, пользователи, заказчики и разработчики.
Инициатором проекта может быть, в принципе, любой из будущих участников проекта. Инициатор проекта выдвигает главную идею, предварительное обоснование и предложения по реализации проекта. Однако, в конечном счёте, деловая инициатива принадлежит заказчику. Так как он может финансировать проект, осуществлять конкурсный отбор альтернативных предложений по проектам и т.п.
Пользователь - это административно-управленческий аппарат, для которого создаётся эта система.
Заказчик - это ответственное лицо (организация, подразделение), которое выполняет функции:
─ формулирует требования к системе и её частям;
─ выдает (утверждает) техническое задание;
─ финансирует разработку информационной системы;
─ обеспечивает проведение комплекса мероприятий по её созданию;
─ проводит приём проекта ИС и внедрение.
Разработчик – это ответственное лицо (организация, подразделение), которое выполняет следующие функции:
─ разрабатывает ИС по техническому заданию заказчика;
─ принимает участие во внедрении;
─ осуществляет сдачу проекта заказчику;
─ осуществляет авторское сопровождение проекта.
С одной стороны, заказчик несёт ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ИС исходным данным пользователя, за сроки создания системы, за правильность использования ресурсов в процессе проектирования.
С другой стороны, заказчик отслеживает, контролирует - осуществляет мониторинг:
─ правильности реализации требований технического задания на ИС;
─ научно - технического уровня разработок;
─ сроков проведения работ;
─ качества проектной документации;
─ правильности расхода денежных ресурсов - выполняемых разработчиком.
Таким образом, представляются отдельные роли участников процесса проектирования.
В реальных условиях некоторые участники процесса проектирования могут выполнять несколько ролей. Мы уже отмечали, что, в конечном счете, инициатором проекта является заказчик. Заказчик, кроме того, может еще выступать и в роли пользователя. Информация необходимая для мониторинга черпается из системы управления проектами.
В двух первых строках матрицы согласованных архитектур (см. таблицу 3.1.) показаны модели, относящиеся к точке зрения будущих пользователей системы, третья строка соответствует точке зрения консультанта – проектировщика, четвертая и пятая строки – точке зрения разработчика информационной системы, шестая строка соответствует точке зрения эксплуатационных служб пользователя.