КИС - Тверской государственный технический университет

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
ТВЕРСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
__________________________________________________________________
КАФЕДРА «ИНФОРМАЦИОННЫЕ СИСТЕМЫ»
Конспект лекций
Лекционный курс по дисциплине «Корпоративные информационные системы»
для студентов специальности «Информационные системы и технологии»
(заочная форма обучения)
Тверь 2009
УДК
025.4.036:004.6(075.8)+025.4.036:004.738.5(075.8);
681.3.01(075.8)+681.324(075.8)
ББК 73.я7+32.81.я7
Конспект лекций по дисциплине "Корпоративные информационные системы" включает
разделы: "Корпоративные системы управления, их свойства, решаемые задачи. Требования к
КИС", "КИС - целостная платформа управления предприятием", "Автоматизированное
управление бизнес-процессами", "Оперативная аналитическая обработка данных в КИС",
"Хранилища данных", "Технологии проектирования КИС", "Основы методологии
проектирования КИС", "Моделирование КИС", "Введение в UML", "Определение потребности,
оценка и выбор CASE-средств", "Выполнение пилотного проекта и внедрение".
Лекционный курс предназначен для студентов специальности «Информационные системы и
технологии», но может быть использован и для других профильных специальностей.
Конспект лекций обсужден и рекомендован к печати на заседании кафедры
«Информационные системы» (протокол № от . .2009 г.).
Составитель: В.К. Иванов
Конспект лекций
Лекционный курс по дисциплине «Корпоративные информационные системы»
для студентов специальности «Информационные системы и технологии»
(заочная форма обучения)
Редактор
Технический редактор
_____________________________________________________________________
Подписано в печать
Формат 60x84/16
Бумага писчая
Физ. печ. л. 2.25 Усл. печ. л. 2.09 Уч.-изд. л. 1.96
Тираж 100 экз.
Заказ №
С_____________________________________________________________________
Типография ТГТУ
 Тверской государственный
технический университет, 2009
 Иванов В.К., 2009
Содержание
СОДЕРЖАНИЕ ................................................................................................................................................................................. 3
1. КОРПОРАТИВНЫЕ СИСТЕМЫ УПРАВЛЕНИЯ, ИХ СВОЙСТВА, РЕШАЕМЫЕ ЗАДАЧИ. ТРЕБОВАНИЯ К
КИС ..................................................................................................................................................................................................... 6
ФАКТОРЫ, ВЛИЯЮЩИЕ НА РАЗВИТИЕ КИС ..................................................................................................................................... 6
ОСНОВНЫЕ СОСТАВЛЯЮЩИЕ КИС .................................................................................................................................................. 7
КЛАССИФИКАЦИЯ КИС .................................................................................................................................................................... 7
Функциональные возможности................................................................................................................................................. 7
Масштаб предприятия .............................................................................................................................................................. 8
Стоимость и сроки внедрения .................................................................................................................................................. 8
Сфера применения ...................................................................................................................................................................... 8
Способ организации .................................................................................................................................................................... 9
ТРЕБОВАНИЯ К КИС ......................................................................................................................................................................... 9
СТАНДАРТЫ КИС ............................................................................................................................................................................. 9
ЗАДАЧИ, РЕШАЕМЫЕ КИС .............................................................................................................................................................. 11
2. КИС - ЦЕЛОСТНАЯ ПЛАТФОРМА УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ ..................................................................... 12
ЗАДАЧА УПРАВЛЕНИЯ ..................................................................................................................................................................... 12
СХЕМА ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ ........................................................................................................................................... 12
СОВРЕМЕННЫЕ ТЕХНОЛОГИИ ОРГАНИЗАЦИИ УПРАВЛЕНИЯ .......................................................................................................... 13
Функциональный подход........................................................................................................................................................... 13
Процессный подход ................................................................................................................................................................... 13
ПРОГРАММНЫЕ ПРОДУКТЫ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ............................................................................................................ 13
Классификация продуктов ....................................................................................................................................................... 13
Западные продукты .................................................................................................................................................................. 14
Российские продукты ............................................................................................................................................................... 14
3. АВТОМАТИЗИРОВАННОЕ УПРАВЛЕНИЕ БИЗНЕС-ПРОЦЕССАМИ ....................................................................... 15
ПОНЯТИЕ WORKFLOW И WORKFLOW MANAGEMENT .................................................................................................................... 15
АРХИТЕКТУРА СИСТЕМЫ WORKFLOW MANAGEMENT ................................................................................................................... 16
СТАНДАРТЫ В ОБЛАСТИ WORKFLOW MANAGEMENT ..................................................................................................................... 16
МОДЕЛЬ WORKFLOW MANAGEMENT С ТОЧКИ ЗРЕНИЯ WFMC ...................................................................................................... 17
ЭТАЛОННАЯ МОДЕЛЬ СИСТЕМЫ WORKFLOW MANAGEMENT (WFMC) ......................................................................................... 17
4. ОПЕРАТИВНАЯ АНАЛИТИЧЕСКАЯ ОБРАБОТКА ДАННЫХ В КИС ....................................................................... 18
ОСНОВНЫЕ ПОНЯТИЯ OLAP .......................................................................................................................................................... 18
Определение............................................................................................................................................................................... 18
Тест FASMI ............................................................................................................................................................................... 18
OLAP и многомерное представление. Кубы ........................................................................................................................... 18
«Разрезание» куба ..................................................................................................................................................................... 19
Метки, иерархии и уровни........................................................................................................................................................ 20
Организации данных в кубах .................................................................................................................................................... 21
ОПЕРАЦИИ МАНИПУЛИРОВАНИЯ ИЗМЕРЕНИЯМИ........................................................................................................................... 21
Формирование «Среза» ............................................................................................................................................................ 21
Операция «Вращение» (rotate) ................................................................................................................................................. 21
Отношение и Иерархические Отношения ............................................................................................................................. 21
Операция Агрегации (Drill Up) ................................................................................................................................................ 22
Операция Детализации (Drill Down)....................................................................................................................................... 22
КОНЦЕПЦИЯ ОПЕРАТИВНОЙ АНАЛИТИЧЕСКОЙ ОБРАБОТКИ ДАННЫХ ............................................................................................ 22
Требования к средствам оперативной аналитической обработки ..................................................................................... 23
Архитектура OLAP-приложений ............................................................................................................................................ 24
Способы аналитической обработки данных ......................................................................................................................... 25
Сравнение характеристик статического и динамического анализа .................................................................................. 25
Области применения анализа данных ..................................................................................................................................... 25
Обобщенная структура информационно-аналитической системы ................................................................................... 26
ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ ...................................................................................................................................................... 27
5. ХРАНИЛИЩА ДАННЫХ ......................................................................................................................................................... 27
ОПРЕДЕЛЕНИЕ ХРАНИЛИЩА ........................................................................................................................................................... 27
СТРУКТУРА ХРАНИЛИЩА ДАННЫХ ................................................................................................................................................. 27
ОСНОВНЫЕ СВОЙСТВА ХД ............................................................................................................................................................. 28
ВИРТУАЛЬНОЕ ХД .......................................................................................................................................................................... 28
ЭТАПЫ ETL-ПРОЦЕССА .................................................................................................................................................................. 30
Схема ETL-процесса ................................................................................................................................................................. 30
Извлечение данных .................................................................................................................................................................... 30
Преобразование данных ........................................................................................................................................................... 30
Очистка данных........................................................................................................................................................................ 31
ХРАНИЛИЩА ДАННЫХ И OLAP...................................................................................................................................................... 32
Многомерный OLAP (MOLAP) ................................................................................................................................................. 32
Реляционный OLAP (ROLAP) ................................................................................................................................................... 33
Схема "звезда"........................................................................................................................................................................... 35
Схема "снежинка" .................................................................................................................................................................... 35
OLAP-КЛИЕНТ ................................................................................................................................................................................ 36
ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ ...................................................................................................................................................... 37
6. ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ КИС ........................................................................................................................ 37
ЧТО ТАКОЕ ОПИСАНИЕ ПРОЕКТА? .................................................................................................................................................. 37
Неформальные подходы ........................................................................................................................................................... 37
Структурные методы ............................................................................................................................................................. 37
Недостатки "ручных" технологий ......................................................................................................................................... 38
CASE-СРЕДСТВА И ТЕХНОЛОГИИ ................................................................................................................................................... 38
Предпосылки появления CASE-средств .................................................................................................................................. 38
Особенности внедрения CASE ................................................................................................................................................. 38
Ключевые факторы успеха внедрения CASE .......................................................................................................................... 38
Общие выводы ........................................................................................................................................................................... 39
ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ ...................................................................................................................................................... 39
7. ОСНОВЫ МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ КИС ................................................................................................. 39
ЖИЗНЕННЫЙ ЦИКЛ КИС ................................................................................................................................................................ 39
СТРУКТУРА ЖЦ .............................................................................................................................................................................. 39
МОДЕЛИ ЖЦ................................................................................................................................................................................... 39
Определение модели ЖЦ .......................................................................................................................................................... 39
Каскадная модель ..................................................................................................................................................................... 39
Каскадная модель с промежуточным контролем ................................................................................................................ 40
Сложности работы по каскадной модели ............................................................................................................................. 40
Спиральная модель ................................................................................................................................................................... 41
ОБЩИЕ ТРЕБОВАНИЯ К МЕТОДОЛОГИИ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИС ............................................................................ 42
СТАНДАРТЫ .................................................................................................................................................................................... 43
Стандарты проектирования .................................................................................................................................................. 43
Стандарт оформления проектной документации ............................................................................................................... 44
Стандарт интерфейса пользователя .................................................................................................................................... 44
МЕТОДОЛОГИЯ RAD ...................................................................................................................................................................... 44
СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА К РАЗРАБОТКЕ КИС ........................................................................................................... 44
ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ ...................................................................................................................................................... 45
8. МОДЕЛИРОВАНИЕ КИС ........................................................................................................................................................ 45
МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0. ОБЩИЕ СВЕДЕНИЯ .................................................................... 45
Основные концепции IDEF0 ..................................................................................................................................................... 45
Типы связей между функциями ............................................................................................................................................... 46
Примеры диаграмм IDEF0 ....................................................................................................................................................... 46
Вопросы для самопроверки ...................................................................................................................................................... 48
ОСНОВЫ МЕТОДОЛОГИИ МОДЕЛИРОВАНИЯ ПОТОКОВ ДАННЫХ. ОБЩИЕ СВЕДЕНИЯ .................................................................... 49
Базовые понятия моделирования ............................................................................................................................................ 49
Построение иерархии диаграмм потоков данных................................................................................................................. 50
Верификация модели DFD ....................................................................................................................................................... 50
Пример иерархии диаграмм DFD ............................................................................................................................................ 50
Вопросы для самопроверки ...................................................................................................................................................... 51
МОДЕЛИРОВАНИЕ ДАННЫХ. ОБЩИЕ СВЕДЕНИЯ ............................................................................................................................ 51
Базовые понятия ....................................................................................................................................................................... 51
CASE-метод Баркера ............................................................................................................................................................... 52
Дополнительные конструкции модели данных ...................................................................................................................... 53
Методология IDEF1 ................................................................................................................................................................. 54
Вопросы для самопроверки ...................................................................................................................................................... 55
9. ВВЕДЕНИЕ В UML .................................................................................................................................................................... 55
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ КИС ...................................................................................................... 55
Сущность .................................................................................................................................................................................. 55
Инкапсуляция............................................................................................................................................................................. 56
Наследование ............................................................................................................................................................................. 56
Полиморфизм ............................................................................................................................................................................ 56
ЧТО ТАКОЕ ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ? ................................................................................................................................. 56
Метод Буча, OMT и UML......................................................................................................................................................... 57
ДИАГРАММЫ UML ......................................................................................................................................................................... 57
Визуальные диаграммы UML ................................................................................................................................................... 57
Диаграммы Вариантов Использования .................................................................................................................................. 57
Диаграммы Последовательности ........................................................................................................................................... 58
Кооперативные диаграммы ..................................................................................................................................................... 59
Диаграммы Классов .................................................................................................................................................................. 60
Диаграммы Состояний ............................................................................................................................................................ 61
Диаграммы Компонентов ........................................................................................................................................................ 62
Диаграммы Размещения ........................................................................................................................................................... 63
ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ И ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ .......................................................... 64
Разработка программного обеспечения ................................................................................................................................. 64
Начальная фаза ВМ .................................................................................................................................................................. 64
Уточнение ................................................................................................................................................................................. 65
Конструирование ...................................................................................................................................................................... 65
Ввод в действие ........................................................................................................................................................................ 65
Вопросы для самопроверки ...................................................................................................................................................... 66
10. ОПРЕДЕЛЕНИЕ ПОТРЕБНОСТИ, ОЦЕНКА И ВЫБОР CASE-СРЕДСТВ ................................................................ 66
ОБЩАЯ ХАРАКТЕРИСТИКА И КЛАССИФИКАЦИЯ CASE-СРЕДСТВ .................................................................................................. 66
КЛАССИФИКАЦИЯ ПО ТИПАМ И КАТЕГОРИЯМ................................................................................................................................ 67
ОПРЕДЕЛЕНИЕ ПОТРЕБНОСТЕЙ В CASE-СРЕДСТВАХ ..................................................................................................................... 67
Первый этап внедрения CASE ................................................................................................................................................. 67
Анализ возможностей организации ........................................................................................................................................ 68
Определение организационных потребностей ...................................................................................................................... 69
Определение критериев успешного внедрения ....................................................................................................................... 69
Разработка стратегии внедрения CASE-средств ................................................................................................................ 70
МОДЕЛЬ ПРОЦЕССА ОЦЕНКИ И ВЫБОРА ......................................................................................................................................... 70
ОЦЕНКА CASE-СРЕДСТВ ................................................................................................................................................................ 71
КРИТЕРИИ ОЦЕНКИ И ВЫБОРА ........................................................................................................................................................ 72
ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ ...................................................................................................................................................... 72
11. ВЫПОЛНЕНИЕ ПИЛОТНОГО ПРОЕКТА И ВНЕДРЕНИЕ .......................................................................................... 73
ЦЕЛИ ПИЛОТНОГО ПРОЕКТА ........................................................................................................................................................... 73
ШАГИ ПИЛОТНОГО ПРОЕКТА .......................................................................................................................................................... 73
ОПРЕДЕЛЕНИЕ ХАРАКТЕРИСТИК ПИЛОТНОГО ПРОЕКТА ................................................................................................................. 74
ПЛАНИРОВАНИЕ ПИЛОТНОГО ПРОЕКТА ......................................................................................................................................... 74
ВЫПОЛНЕНИЕ ПИЛОТНОГО ПРОЕКТА ............................................................................................................................................. 75
ОЦЕНКА ПИЛОТНОГО ПРОЕКТА ...................................................................................................................................................... 75
ПРИНЯТИЕ РЕШЕНИЯ О ВНЕДРЕНИИ ............................................................................................................................................... 75
ПЛАН ПЕРЕХОДА ............................................................................................................................................................................. 76
ДЕЙСТВИЯ, ВЫПОЛНЯЕМЫЕ В ПРОЦЕССЕ ПЕРЕХОДА ..................................................................................................................... 76
ОЦЕНКА РЕЗУЛЬТАТОВ ПЕРЕХОДА .................................................................................................................................................. 77
ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ ...................................................................................................................................................... 77
1. Корпоративные системы управления, их свойства,
решаемые задачи. Требования к КИС
Корпоративная информационная система (КИС) – это определенная совокупность методов и решений для
создания информационного пространства управления и обеспечения деятельности компании.
КИС = технологические средства + ПО +данные жизнедеятельности предприятия
Цель: максимально оптимизировать бизнес – процессы, структуру и методы управления.
Факторы, влияющие на развитие КИС
1. Развитие методик управления предприятием.
2. Развитие общих возможностей и производительности компьютерных систем (развитие сетевых технологий
и систем передачи данных, интеграция ПК с различным оборудованием).
3. Развитие подходов к технологической и программной реализации элементов информационных систем.
Среди них наибольшее влияние имели:
a) объектно-ориентированное программирование
b) сетевые технологии: клиент-сервер и многоуровневые
c) развитие сети Интернет для работы с удаленными клиентами, Интернет-технологии (использование
Интернет в корпоративных сетях)
Можно выделить 3 группы методов управления:
1. ресурсами (бухгалтерия, финансы, кадры, логистика)
2. процессами (документооборот, производство, качество, проекты)
3. корпоративными знаниями – коммуникациями
Основные составляющие КИС
1. Компьютерная инфраструктура (сетевая, телекоммуникационная, программная, информационная и
организационная) или корпоративная сеть.
2. Функциональные подсистемы. Зависят от специфики задач,
инфраструктуре и определяют прикладную функциональность.
базируются
на
компьютерной
КИС может быть реализована на существующем интегрированном программно-аппаратном комплексе или
создана «с нуля» посредством единого решения.
Разработку и внедрение функциональных подсистем можно выполнять постепенно (финансовый учет,
управление кадрами и т.п.).
Классификация КИС
1. по функциональным возможностям
2. по масштабу предприятия
3. по стоимости внедрения проекта (лицензия + услуги внедрения)
4. по срокам внедрения
5. по сфере применения
6. по используемым информационным технологиям
Функциональные возможности
1. Бухгалтерский учет
Легко формируется, но разработка весьма трудоемка, так как повышенные требования к надежности, простоте и
удобству в эксплуатации.
2. Управление финансовыми потоками
Расчеты с поставщиками и покупателями. Весьма критично к ошибкам, поэтому должно быть точно просчитано и
жестко контролируемо. Цель – увеличить оборотные средства предприятия.
3. Управление складом, ассортиментом, закупками (логистические цепочки).
Автоматизация процесса движения товара. Цель – получить максимальную прибыль при постоянной нехватке
средств, то есть отследить те 20% товара, которые приносят 80% прибыли.
4. Управление производственным процессом.
Сложная задача. Автоматизация дает возможность грамотно планировать и учитывать затраты, проводить
техническую подготовку производства, оперативно управлять процессом выпуска продукции в соответствии с
производственной программой и технологией.
5. Управление маркетингом
Подразумевает сбор и анализ данных о фирмах-конкурентах, их продукции, ценах, а также моделирование
параметров внешнего окружения для определения оптимального уровня цен, прогнозирования прибыли и
планирования рекламных компаний.
6. Документооборот
Автоматизация позволяет отражать реальную производственную деятельность и возможность воздействовать
на нее.
7. Оперативное управление предприятием
Это общая база данных предприятия, используемая в бизнес-процессах. По сути, это и есть КИС.
8. Предоставление информации о фирме
Предполагается наличие Web-сервера предприятия для решения задач:
a) создания имиджа предприятия
b) предоставление информации о фирме, предлагаемых товарах и услугах существующим и
потенциальным клиентам
c) электронная коммерция
Масштаб предприятия
Предприятия:
 крупные корпорации и монополии
 средний бизнес
 малый бизнес
 бюджетные
ИС:
 одиночные
- нет сети
- локальные СУБД (FoxPro, Access)
 групповые
- ЛВС
- «клиент-сервер»
- SQL-серверы (Oracle, DB2, Microsoft SQL Server, Sybase)
 корпоративные
- могут поддерживать территориально разнесенные узлы (Интернет)
- иерархическая структура (Oracle, DB2, Microsoft SQL Server)
Стоимость и сроки внедрения
Для крупных корпораций: стоимость от $150 – 300 тыс.; сроки внедрения год и больше («Галактика»).
Для среднего бизнеса: стоимость от $840 – 880 тыс.; сроки внедрения 2-3 мес. («Парус», «Аксанта»)
Для малого бизнеса: несколько тыс.$ (1С:Предприятие)
Для бюджетных: «Парус», «Галактика».
Сфера применения
 системы обработки транзакций (СУБД)
 системы принятия решение
 информационно-справочные системы
 офисные информационные системы
Системы обработки транзакций разделяются на пакетные и оперативные.
Оперативные – для управления (OLTP – Online Transaction Processing). Транзакции: заказы, платежи, запросы.
Требования: высокая производительность обработки транзакции; гарантированная доставка информации при
удаленном доступе к БД.
Системы поддержки принятия решений – DSS (Decision Support System). Используются сложные запросы, с
помощью которых производится отбор и анализ данных в различных разрезах: временном, географическом и
др.
Информационно справочные системы основаны на гипертекстовых документах и мультимедиа.
Офисные информационные системы - автоматизация делопроизводства и управления документооборотом.
Примечание: КИС обычно состоят из ряда подсистем, относящихся к различным сферам применения.
Способ организации
 на основе архитектуры файл-сервера (FS)
 модель удаленного доступа к данным (Remote Data Access – RDA)
 модель сервера базы данных (Data Base Server – DBS)
 модель сервера приложений - многоуровневая архитектура (Application Server – AS)
 модель Интернет/Интранет
Все это модели «клиент-сервер». В этой технологии не выполняется основной принцип распределенных систем
– отсутствие центральной установки, так как в ее основе два принципа:
 общие данные на одном или нескольких серверах
 много клиентов на различных вычислительных установках, совместно обрабатывающих данные
То есть такие системы распределены только в отношении пользователей, поэтому давно стали отдельным
классом многопользовательских систем.
Сервер приложений может выполнять несколько прикладных функций, каждая – как отдельная служба.
Серверов AS может быть несколько (каждый для отдельных услуг).
Требования к КИС
1. Системный подход к комплексу задач управления
2. Наличие СУБД и клиент-серверных технологий обработки
3. Безопасность
4. Контроль и разграничение прав доступа
5. Модульный принцип построения из оперативно-функциональных блоков
6. Поддержка Интернет и Интранет
7. Поддержка принятых стандартов управления
8. Русифицированный эргономический интерфейс
Стандарты КИС
В основе построения и использования КИС должна лежать четкая управленческая методология, объединяющая
бизнес-стратегию предприятия (с встроенной для этого структурой) и информационные технологии.
В качестве стандартов управления (принятых de factо) используются зарубежные: MRP, MRP II, ERP +
дополнения.
1. ERP (Enterprise Resource Planning) – системы планирования ресурсов предприятия, ядром которых
является MRP II (Manufacturing Resource Planning – планирование производственных ресурсов)
2. CRM (Customer Relationship Management) – система управления взаимоотношений с клиентами, состоящая
из:
a) MA(Marketing Automation) – автоматизация маркетинга
b) CS(Customer Service) – обслуживание клиентов
c) SFA(Sales Force Automation) – автоматизация продвижения продаж
d) SCM(Supply Chain Management) – системы управления цепочкой поставок
Стандарты MRP – ERP развивались эволюционно.
CSRP – планирование ресурсов синхронизированное с потреблением (Customer Synchronized Resource
Planning).
В основе систем MRP – принцип управления материальными запасами. Цель: формировать, контролировать и
изменять моменты заказов так, чтобы все требуемые материалы поступали одновременно.
MRP II – для эффективного планирования всех ресурсов производства, в том числе финансовых и кадровых.
Для материальных ресурсов, в отличие от MRP, используется «замкнутый цикл» планирования, то есть
созданные отчеты могут изменить производственную программу и план заказов.
В дальнейшем: система MRP II + финансовый план (FRP – finance requirements planning) = системы бизнеспланирования ERP.
ERP системы также предназначены для планирования всей коммерческой деятельности современного
предприятия, в том числе финансовых затрат на обновление оборудования и инвестиций в производство.
Лучше подходят для учета условий инфляции и жестких налоговых условий.
В системах класса CSRP учитываются также и вспомогательные затраты, связанные с маркетингом, продажей и
последующим обслуживанием.
Дальнейшее развитие методик управления – идея виртуального бизнеса, представляющего полный жизненный
цикл товара, или разделение одной компании на несколько «виртуальных бизнесов».
Все эти технологии воплощены как в отдельных программных продуктах, так и в рамках Интранет.
В телекоммуникационных технологиях выделяют 3 уровня реализации:
 аппаратный
 программный
 информационный
С этой точки зрения Интранет отличается от Интернета только информационным уровнем, где выделяют:
 универсальный язык представления корпоративных знаний
 модели представления
 фактические знания
Язык не зависит от предметной области, определяет грамматику и синтаксис. В настоящее время единого языка
нет. К нему можно отнести графический язык описания моделей данных, сетевых графиков, алгоритмов.
Модели представления – определяют специфику предметной деятельности. Являются метаданными,
описывающими первичные данные.
Фактические знания – первичные данные.
Задачи, решаемые КИС
Выделяют 3 класса задач, решаемых КИС:
 Формирование отчетных показателей, получаемых на основе стандартной бухгалтерской и статистической
отчетности
 Выработка стратегических управляющих решений на основе агрегированных показателей
 Выработка тактических решений, направленных на оперативное управление на основе частных
высокодетализированных показателей.
Основная трудность при внедрении КИС – диагностика. Три этапа:
 Обследование, системный анализ и оценка существующей структуры и технологий управления
 Разработка новых вариантов
информационных технологий
организационных
структур
и
технологий
управления
на
основе
 Разработка положения по реорганизации управления, плана внедрения регламента управленческого
документооборота
Условно выделяют КИС: тиражируемые, полузаказные и заказные.
Тиражируемые – не имеют возможности внесения изменений. Используются в малом бизнесе.
Заказные – использовать неэффективно, так как они не соответствуют принятым стандартам, трудно
модернизировать. Применяются на производствах с большой спецификой.
Полузаказные – наиболее гибкие, в большей степени удовлетворяют требованиям заказчика, требуют меньших
капитальных затрат.
2. КИС - целостная платформа управления предприятием
Цель – поддержка функционирования и развития предприятия. Результаты создания и эксплуатации КИС
должны позволить предприятию быстро увеличивать прибыль за счет эффективного управления на различных
уровнях.
Задача управления
Это наилучшая организация преобразования поступающих на вход ресурсов в конечный результат.
Схема деятельности предприятия
Структура и принцип работы любой организации могут быть описаны характерными объективными законами
управления, регламентирующими управляющее воздействие на систему.
На первом уровне – данные о ресурсах (финансовых, материальных, кадровых, информационных). Здесь они
собираются и накапливаются.
На втором уровне (уровне знаний) и на третьем (тактическом) КИС хранит и обрабатывает структурированные
(то есть систематизированные в соответствии с требованиями среднего управляющего персонала)
корпоративные данные.
Четвертый уровень (стратегический) содержит системы поддержки принятия решений (содержат средства
многомерного анализа данных, инструменты аналитической обработки). Используются специальные
математические методы, позволяющие прогнозировать динамику развития различных показателей,
анализировать затраты по различным видам деятельности, формировать подробные бюджеты по разным
схемам.
Современные технологии организации управления
Есть два подхода (принципа) к организации управления на предприятии: традиционный функциональный
(задачный) и процессный.
Архитектура ИС разрабатывается исходя из конкретного принципа.
Функциональный подход
Основные черты:
 строгая вертикальная иерархия управления
 жесткое разделение труда, сгруппированное в соответствии со спецификой выполняемых действий
 управление, ориентированное на выполнение однородных действий
Недостаток: нет прямой связи между подразделениями при развитии бизнес-процесса (связь между
руководителями с целью согласования результатов работы отдельных подразделений).
Это технология сборочного конвейера. Значит, отсутствует мотивация работника (его заинтересованность в
конечном результате).
В функционально-ориентированном бизнесе 20% времени – выполнение операции, 80% - передача
информации. Вывод:
 отсутствие структурированной системы получения данных от подразделений; есть фрагментарные отчеты,
но нет единой системы
 несогласованность действий между способами
 дублирование работ
 отсутствие отлаженной системы документооборота между отделами
Процессный подход
Основан на использовании бизнес-модели предприятия, которая определяет взаимодействие бизнес-процессов
(не ограничиваясь отдельными подразделениями).
Право принятия решений и ответственность за них передается работникам, компетентным в своих областях.
Работник четко знает и цели своего предприятия, и свою роль в общем деле.
Пример: в экономике Японии подъем произошел после перехода компаний на процессное управление. Сейчас
отдельные бизнес-процессы патентуются, покупаются.
Возможность гибко перестраивать организационную структуру
специализацию компании называется «бизнес-реинжиниринг».
предприятия,
процесс
производства
Реинжиниринг = ОриентацияНаПроцессы + УдовлетворениеПотребностейКлиента + НовыеПравилаРаботы +
НовыеИнформационноКоммуникативныеТехнологии
«Горизонтальные» предприятия характеризуются тем, что мало решается задач для обеспечения внутренней
жизнедеятельности, а много – для удовлетворения интересов заказчика.
Для этого нужно:
 специальное ПО процессов координации (Coordination Software)
 новые профессиональные качества менеджеров среднего звена
Программные продукты управления предприятием
Классификация продуктов
Можно разделить на 3 группы:
Западные продукты
R/3 (SAP) – Германия (или SAP AG), Oracle (Oracle Application)- США, Baan IV, V (Baan), Scala (Scala), One Word
I.D.Edvards (I.D.Edvards), People Soft (People Soft) и др.
Стоимость 1 рабочего места около 7000$ и выше; общая стоимость около $300 тыс.
Это крупные интегрированные комплексы ERP-класса (кроме управления производством еще модули
CRM,ASP(автоматизация продаж),OLAP).
Средние КИС: Attain Axapta (компания Navision в составе Microsoft). Стоимость 1 рабочего места
приблизительно 1000-1700$ для малого бизнеса и от 1500$ для среднего.
Западные КИС опираются на западные технологии ведения бизнеса.
Российские продукты
Галактика (Галактика), Парус-корпорация (Парус), 1С:Предприятие (1С), 1С:Рарус (1С:Рарус), Эталон (Цефей),
БОСС-корпорация (АйТи), NS2000 (Никос-Софт), Тектон (ИнтелГрупп), БЭСТ-ПРО (Интеллект-Сервис), Флагман
(ИНФОСОФТ).
Их отличия: более низкая стоимость, учет отечественной специфики, возможность изменения бухгалтерского и
налогового учета.
В информатизации банковской деятельности выделяют два направления:
 Информатизация задач ввода и обновления оперативной информации,
отчетности(OLTP-системы - Online Transaction Processing на базе СУБД).
получение
стандартной
 Информатизация аналитических задач высокого уровня (анализ деятельности банка, получение
консолидированного отчета, расчет и управление рисками и др.). Используется технология
информационных хранилищ (Data Warehouse), приложения оперативной аналитической обработки
OLAP(Online Analytic Processing) и средств интеллектуального анализа данных (Data Wining).
Примеры банковских ИС: “RS-Bank 4”, “DiasoftBank 4.4”, “InvoBank”.
Кроме КИС используются программные системы, реализующие отдельные функции управления:
 Информационно-бухгалтерские: 1С:Бухгалтерия, БЭСТ, Парус
 Информационно-справочные: Гарант, Консультант Плюс, Кодекс
 Программы для бизнес-планирования: Project Expert, Microsoft Project/
3. Автоматизированное управление бизнес-процессами
Понятие Workflow и Workflow Management
Workflow Management – это технология автоматизированного управления потоком работ (и через него бизнеспроцессом).
То есть автоматизированные прием/передача информации с одного рабочего места на другое. Это
автоматизация процессов, а не отдельных функций. Такие системы позволяют автоматически отслеживать
последовательность и время выполнения функций, маршрута документов, контроля загрузки участников
процесса на различных его стадиях.
Источники данных (возможно, использовать различные приложения, которые были до реорганизации)
Разработчик Workflow(Workflow Designer)-формальное описание Workflow:
 КТО (пользователь)
 КОГДА (сроки)
 НАД ЧЕМ (данные)
 ЧТО (операции над данными)
Архитектура системы Workflow Management
Фактически такие системы позволяют организовать эффективную обратную связь для управления организацией.
В любой момент бизнес-аналитик может получить отчет в любом разрезе. Появляется возможность
динамически совершенствовать процессы.
Workflow Management может использоваться как промежуточный вариант при внедрении ERP-системы, так как в
этом случае придется отказаться от всех работающих приложений.
Стандарты в области Workflow Management
Их устанавливают организации:
 Workflow Management Coalition (WfMC) – некоммерческая (1993 г.)
 Business Process Management Initiative (BMPI.org) – некоммерческая (2000 г.)
 Workflow and Reengineering International Association (WARIA)
WfMC – разработка единых стандартов для обеспечения взаимодействия между разнородными продуктами
Workflow и их интеграция с электронной почтой, системами распознавания, управления документооборотом и
т.д.
Разработано:
 референтная модель Workflow
 терминология
 спецификация Workflow API (WAPI) для клиентских приложений
 спецификация по аудиту данных в Workflow
 рекомендации по разработке стандартов для языка моделирования бизнес-процессов – BPML (Business
Process Modeling Language). В России интересы WfMC – компания «Логика Бизнеса»
BMPI.org – разрабатывает стандарты и средства для решения задач интеграции бизнес-процессов.
Разработано:
 BPML (Business Process Modeling Language) – мета-язык для моделирования бизнес-процессов
 BPNM – нотации по моделированию, позволяют представить бизнес-процессы как диаграмму –
спецификация для связи нотаций
 BPQL – язык запросов бизнес-процесса (Business Process Query Language). Язык запросов между
системами управления бизнес-процессами
Модель Workflow Management с точки зрения WfMC
Workflow – автоматизация (полностью/частично) бизнес-процесса, при которой документы, информация, задания
передаются в соответствии с набором процедурных правил. Системы управления Workflow – это ПО, которое
описывает, создает, управляет потоком работ.
Основные понятия и соотношения
Экземпляры процесса – версии, отличающиеся потоками данных.
Заявка нового клиента – очередной экземпляр.
В результате получают либо новые объекты, либо вызовы приложений (считывание из БД, запись).
Описание процесса – набор функций, а экземпляр – частный случай с конкретными входными данными.
Эталонная модель системы Workflow Management (WfMC)
Определяет архитектуру взаимодействия в следующих областях:
 импорт и экспорт описаний процессов
 взаимодействие с клиентским приложением и программой-обработчиком списка работ
 вызов программных инструментов приложений
 взаимодействие между различными системами Workflow
 функции администрирования и мониторинга
4. Оперативная аналитическая обработка данных в КИС
Основные понятия OLAP
Определение
OLAP - это Online Analytical Processing, т. е. оперативный анализ данных. 12 определяющих принципов OLAP
сформулировал в 1993 г. Е. Ф. Кодд - "изобретатель" реляционных БД. Позже его определение было
переработано в так называемый тест FASMI.
Тест FASMI
OLAP - это Online Analytical Processing, т. е. оперативный анализ данных. 12 определяющих принципов OLAP
сформулировал в 1993 г. Е. Ф. Кодд - "изобретатель" реляционных БД. Позже его определение было переработано в
так называемый тест FASMI.
Fast (Быстрый) - анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время
отклика - 5 с или менее.
Analysis (Анализ) - должна быть возможность осуществлять основные типы числового и статистического анализа,
предопределенного разработчиком приложения или произвольно определяемого пользователем.
Shared (Разделяемой) - множество пользователей должно иметь доступ к данным, при этом необходимо
контролировать доступ к конфиденциальной информации.
Multidimensional (Многомерной) - это основная, наиболее существенная характеристика OLAP.
Information (Информации) - приложение должно иметь возможность обращаться к любой нужной информации,
независимо от ее объема и места хранения.
OLAP и многомерное представление. Кубы
Пользователь OLAP получает естественную, интуитивно понятную модель данных, организуя их в виде многомерных
кубов (Cubes). Осями многомерной системы координат или измерениями (Dimensions) служат основные атрибуты
анализируемого бизнес-процесса. На пересечениях осей (измерений) в ячейках находятся данные, количественно
характеризующие процесс - меры (Measures) или показатели.
Измерение – множество однотипных данных, образующих одну из граней куба (например: дни, месяцы,
кварталы, годы). Они играют роль индексов для значений показателей, находящихся в ячейках.
Так как для каждого куба может быть определено несколько показателей, то комбинация членов всех измерений
будет определять несколько ячеек со значениями каждого показателя. Поэтому уже при однозначной
идентификации ячейки необходимо указать комбинацию членов всех измерений и показатель.
Пользователь, анализирующий информацию, может "разрезать" куб по разным направлениям, получать сводные
(например, по годам) или, наоборот, детальные (по неделям) сведения и выполнять другие действия, которые ему
придут в голову в процессе анализа. В качестве мер в трехмерном кубе, изображенном на рис. 4.1, использованы
суммы продаж, а в качестве измерений - время, товар и магазин. Измерения представлены на определенных уровнях
группировки: товары группируются по категориям, магазины - по странам, а данные о времени совершения операций по месяцам.
Март
Февраль
8000
12000
7000
Январь
820
500
1000
900
600
950
США
Мексика
Россия
Напитки
10000
1000
1200
Продукты
питания
12000
800
1500
Прочие
товары
500
120
150
Рис. 4.1. Пример куба
«Разрезание» куба
Даже трехмерный куб сложно отобразить на экране компьютера так, чтобы были видны значения интересующих мер.
О кубах с количеством измерений больше трех можно и не говорить. Для визуализации данных, хранящихся в кубе,
применяются, как правило, привычные двумерные (табличные) представления.
Двумерное представление куба можно получить, "разрезав" его поперек одной или нескольких осей (измерений): мы
фиксируем значения всех измерений, кроме двух, - и получаем обычную двумерную таблицу. В горизонтальной оси
таблицы (заголовки столбцов) представлено одно измерение, в вертикальной (заголовки строк) - другое, а в ячейках
таблицы - значения мер. При этом набор мер фактически рассматривается как одно из измерений - мы либо выбираем
для показа одну меру (и тогда можем разместить в заголовках строк и столбцов два измерения), либо показываем
несколько мер (и тогда одну из осей таблицы займут названия мер, а другую - значения единственного
"неразрезанного" измерения).
Примеры
1. Двумерный срез куба для одной меры – "Продано штук" и двух "неразрезанных" измерений – "Место продажи" и
"Время" (Рис. 4.2).
США
Мексика
Россия
Январь
7000
600
950
Февраль
12000
500
900
Март
8000
820
1000
Рис. 4.2. Двумерный срез куба для одной меры
2. Одно "неразрезанное" измерение – "Место продажи" и значения нескольких мер – "Продано штук", "Сумма продажи"
и "Расходы магазина" (Рис. 4.3).
США
Мексика
Россия
Продано штук
27000
1920
2850
Сумма продажи
300000
3000
45000
Расходы магазина
150000
10000
15000
Рис. 4.3. Двумерный срез куба для нескольких мер
3. Несколько "неразрезанных" измерений – "Место продажи", "Время" и значения нескольких мер – "Продано штук",
"Сумма продажи" и "Расходы магазина" (Рис. 4.4).
Январь
Февраль
США
Мексика
Россия
США
Мексика
Россия
Продано штук
7000
600
950
12000
500
900
Сумма продажи
105000
9000
15000
12000
7600
13000
Расходы магазина
150000
10000
15000
60000
3500
4500
Рис. 4.4. Двумерный срез куба с несколькими измерениями на одной оси
Метки, иерархии и уровни
Значения, "откладываемые" вдоль измерений, называются членами или метками (members). Метки используются как
для "разрезания" куба, так и для ограничения (фильтрации) выбираемых данных. Значения меток отображаются в
двумерном представлении куба как заголовки строк и столбцов.
Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней (levels). Например, метки
измерения "Магазин" (Store) естественно объединяются в иерархию с уровнями:
Весь мир
Страна
Регион
Область
Город
Магазин
В соответствии с уровнями иерархии вычисляются агрегатные значения, например, объем продаж для России
(уровень "Страна") или для Тверской области (уровень "Область"). В одном измерении можно реализовать более
одной иерархии - скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.
Иерархии в измерениях необходимы для возможности агрегации и детализации значений показателей.
Существуют типы иерархий:
 сбалансированная
 несбалансированная
 неровная
Сбалансированная – по высоте, число уровней неизменно, каждая ветвь иерархического дерева содержит
объекты каждого из уровней.
Несбалансированная – число уровней может быть изменено, и каждая ветвь иерархического дерева может
содержать объекты, принадлежащие не всем уровням, только нескольким первым. Как правило, это объекты
одного типа. Например, несбалансированная иерархия типа «начальник-подчиненный», тип всех объектов –
«сотрудник».
Неровная – число уровней постоянно, но некоторые ветви могут содержать объекты, принадлежащие не всем
уровням. Например, географическая иерархия с уровнями «Страны», «Штаты», «Города» (есть страны без
штатов, т.е. есть объекты, логические «родители» которых не находятся на непосредственно вышестоящем
уровне).
Организации данных в кубах
Используются варианты организации данных:
 гиперкубическая
 поликубическая
Поликубическая – может быть несколько гиперкубов с различной размерностью и с различными измерениями в
качестве их граней.
Например:
 двумерный гиперкуб – для показателя «рабочее время менеджера»
 трехмерный – для «объема продаж»
В случае гиперкубической модели предполагается, что все показатели должны определяться одинаковым
набором измерений.
Операции манипулирования измерениями
Формирование «Среза»
Подмножество гиперкуба, получившееся в результате фиксации значения одного или более измерений,
называется срезом (slice).
Например, если взять один член измерения модели – «Волга», то получим подмножество (двумерную таблицу),
содержащую информацию об истории продажи различными менеджерами в различные годы.
Операция «Вращение» (rotate)
Это представление (визуализация) информации. Обычно применяется при двумерном представлении данных.
Применяется для удобства пользователя.
Отношение и Иерархические Отношения
Измерений может быть много и между их значениями существует множество различных отношений (Relation)
типа 1:М.
Например, каждый менеджер может работать только в одном подразделении, а каждой модели автомобиля
однозначно соответствует фирма.
Менеджер  Подразделение
Модель  Фирма-производитель
Множество отношений может иметь иерархическую структуру – это иерархические отношения.
День  Месяц  Квартал  Год (для измерений время отношения устанавливается автоматически)
Менеджер  Подразделение  Регион  Фирма  Страна
Модель  Завод  Производитель  Страна
Часто удобно не объявлять новые измерения и затем детализировать между ними отношения, а использовать
иерархические отношения. В этом случае все потенциально возможные значения из разных измерений
объединяются в одно множество.
Например, Менеджер (Петров, Иванов, Сидоров, Смирнов)  Подразделение (филиал1, филиал2, филиал3) 
Регион (Восток, Запад)  Фирма (НВ, НА) и определить между ними отношение иерархии.
Восток  НА
Запад  НВ
Филиал1  Восток
Филиал2  Восток
Филиал3  Запад
Петров  Филиал1
Сидоров  Филиал2
Иванов  Филиал3
Смирнов  Филиал2
Операция Агрегации (Drill Up)
С точки зрения пользователя Подразделение, Регион, Фирма, Страна являются точно такими же измерениями,
как и Менеджер. Но каждое из них соотносит новому, более высокому уровню агрегации значений показателя
ОбъемПродаж (в процессе анализа пользователь не только работает с различными Срезами данных и
выполняет их Вращение, но и переходит от детализированных данных к агрегированным, то есть производит
операцию Агрегации).
Например, посмотрев, как Петров в 2001 году продавал Жигули и Волгу можно посмотреть соотношение продаж
этих моделей на уровне Подразделения, где работает Петров. А затем аналогично по Региону или Фирме.
Операция Детализации (Drill Down)
Обратный переход от агрегированных данных к детальным.
Например, начав анализ на уровне Региона, можно получить более точную информацию о работе конкретного
Подразделения или Менеджера.
Концепция оперативной аналитической обработки данных
В основе концепции OLAP лежит принцип многомерного представления данных. Основные идеи следующие:
Многомерное концептуальное представление представляет собой множественную перспективу, состоящую из
нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности
данных.
Одновременный анализ по нескольким измерениям определяется как многомерный анализ.
Каждое измерение включает направления консолидации данных, состоящие из серии последовательных
уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по
соответствующему измерению.
Анализ данных включает в себя произвольный выбор желаемого уровня детализации информации по каждому
из измерений.
Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней
обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два
направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по
месяцам и по неделям несовместим.
Операция спуска (drillingdown) соответствует движению от высших ступеней консолидации к низшим; напротив,
операция подъема (rollingup) означает движение от низших уровней к высшим (рис. 4.5).
Спуск
(drilling down)
Исполнитель
Время
Предприятие
Год
Подразделение
Квартал
Отдел
Месяц
Служащий
Подъем
(rolling up)
Неделя
День
Рис. 4.5. Измерения и направления консолидации данных
Часто аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение
самих данных в многомерной БД. Вообще говоря, это неверно, поскольку сам Кодд отмечает, что
"Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных
данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа,
дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и
автоматизировать разные виды интеллектуального анализа, присущие OLAP".
Требования к средствам оперативной аналитической обработки
Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP (табл. 2.1). Это
рекомендательный набор требований. Конкретные продукты следует оценивать по степени приближения к
идеально полному соответствию всем требованиям.
Таблица 2.1. Правила оценки программных продуктов класса OLAP
1.
Многомерное концептуальное
представление данных (MultiDimensional Conceptual View)
2.
Прозрачность (Transparency)
3.
Доступность (Accessibility)
4.
Устойчивая производительность
(Consistent Reporting Performance)
Концептуальное представление модели данных в продукте
OLAP должно быть многомерным по своей природе, то есть
позволять аналитикам выполнять интуитивные операции
"анализа вдоль и поперек" ("sliceanddice"), вращения (rotate) и
размещения (pivot) направлений консолидации.
Пользователь не должен знать о том, какие конкретные
средства используются для хранения и обработки данных, как
данные организованы и откуда берутся.
Аналитик должен иметь возможность выполнять анализ в
рамках общей концептуальной схемы, но при этом данные
могут оставаться под управлением оставшихся от старого
наследства СУБД.
С увеличением числа измерений и размеров базы данных
аналитики не должны столкнуться с каким бы то ни было
уменьшением производительности.
5.
Клиент - серверная архитектура
(Client-Server Architecture)
6.
Равноправие измерений (Generic
Dimensionality)
7.
Динамическая обработка
разреженных матриц (Dynamic Sparse
Matrix Handling)
8.
Поддержка многопользовательского
режима (Multi-User Support)
9.
Неограниченная поддержка
кроссмерных операций (Unrestricted
Cross-dimensional Operations)
10.
Интуитивное манипулирование
данными (Intuitive Data Manipulation)
11.
Гибкий механизм генерации отчетов
(Flexible Reporting)
12.
Неограниченное количество
измерений и уровней агрегации
(Unlimited Dimensionsand Aggregation
Levels)
Способность продуктов OLAP работать в среде клиентсервер. Главная идея - серверный компонент OLAP должен
обладать способностью строить общую концептуальную схему
на основе обобщения и консолидации различных логических и
физических схем корпоративных баз данных для обеспечения
эффекта прозрачности.
Все измерения данных должны быть равноправны.
Дополнительные характеристики могут быть предоставлены
отдельным измерениям, но поскольку все они симметричны,
данная дополнительная функциональность может быть
предоставлена любому измерению. Базовая структура
данных, формулы и форматы отчетов не должны опираться
на какое-то одно измерение.
Инструмент OLAP должен обеспечивать оптимальную
обработку разреженных матриц. Скорость доступа должна
сохраняться вне зависимости от расположения ячеек данных
и быть постоянной величиной для моделей, имеющих разное
число измерений и различную разреженность данных.
Инструмент OLAP должен позволять работу с одной
аналитической моделью одновременно нескольким
аналитикам или создавать различные модели на основе
одних корпоративных данных, предоставлять конкурентный
доступ к данным, обеспечивать целостность и защиту данных.
Вычисления и манипуляция данными по любому числу
измерений не должны запрещать или ограничивать любые
отношения между ячейками данных. Преобразования,
требующие произвольного определения, должны задаваться
на функционально полном формульном языке.
Переориентация направлений консолидации, детализация
данных в колонках и строках, агрегация и другие
манипуляции, свойственные структуре иерархии направлений
консолидации, должны выполняться в максимально удобном,
естественном и комфортном пользовательском интерфейсе.
Должны поддерживаться различные способы визуализации
данных, то есть отчеты должны представляться в любой
возможной ориентации.
Настоятельно рекомендуется допущение в каждом серьезном
OLAP инструменте как минимум пятнадцати, а лучше
двадцати, измерений в аналитической модели. Более того,
каждое из этих измерений должно допускать практически
неограниченное количество определенных пользователем
уровней агрегации по любому направлению консолидации.
Архитектура OLAP-приложений
Многомерность в OLAP-приложениях может быть разделена на три уровня:
1. Многомерное представление данных - средства конечного пользователя, обеспечивающие многомерную
визуализацию и манипулирование данными; слой многомерного представления абстрагирован от физической
структуры данных и воспринимает данные как многомерные.
2. Многомерная обработка - средство (язык) формулирования многомерных запросов (традиционный реляционный
язык SQL здесь оказывается непригодным) и процессор, умеющий обработать и выполнить такой запрос.
3. Многомерное хранение - средства физической организации данных, обеспечивающие эффективное выполнение
многомерных запросов.
Первые два уровня в обязательном порядке присутствуют во всех OLAP-средствах. Третий уровень не обязателен
(данные для многомерного представления могут извлекаться и из обычных реляционных структур; многомерные
запросы транслируются в SQL-запросы для СУБД.).
Конкретные OLAP-продукты, как правило, представляют собой либо средство многомерного представления данных,
OLAP-клиент (например, PivotTables в MS Excel), либо многомерную серверную СУБД или OLAP-сервер (например,
Oracle Express Server или Microsoft OLAP Services).
Способы аналитической обработки данных
Информационно-аналитические системы или системы поддержки принятия решений (СППР) бывают:
 Статические.
Иногда называются Информационными системами руководителя (ИСР), или Executive Information Systems (EIS).
Просты в применении, но ограничены в функциональности. Содержат предопределенные множества запросов.
Достаточны для повседневного обзора, но неспособны ответить на все вопросы к имеющимся данным, которые
могут возникнуть при принятии решений. Каждый новый запрос, непредусмотренный при проектировании
такой системы, должен быть сначала формально описан, закодирован программистом и только затем
выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо.
Внешняя простота статических СППР, за которую активно борется большинство заказчиков
информационно-аналитических систем, оборачивается катастрофической потерей гибкости.
 Динамические.
Ориентированы на обработку нерегламентированных (adhoc) запросов к данным. Работа аналитиков с этими
системами заключается в интерактивной последовательности формирования запросов и изучения их
результатов.
Сравнение характеристик статического и динамического анализа
Характеристика
Статический анализ
Динамический анализ
Типы вопросов
Сколько? Как? Когда?
Почему? Что будет если?
Время отклика
Не регламентируется
Секунды
Типичные операции
Регламентированный
диаграмма
отчет, Последовательность
интерактивных
отчетов, диаграмм, экранных форм.
Динамическое
изменение
уровней
агрегации и срезов данных.
Уровень аналитических Средний
требований
Тип экранных форм
Уровень
данных
Высокий
В основном определенный заранее, Определяемый пользователем
регламентированный
агрегации Детализированные и суммарные
текущие
В основном суммарные
Возраст данных
Исторические
и
прогнозируемые
и Исторические,
прогнозируемые
текущие
и
Типы запросов
В основном предсказуемые
Назначение
Регламентированная аналитическая Многопроходный
анализ,
обработка
моделирование и построение прогнозов
Непредсказуемые, от случаю к случаю
Области применения анализа данных
 Детализированные данные. Используются системы, ориентированные на поиск информации (как правило,
реляционные СУБД). Стандарт языка манипулирования данными - SQL. Информационно-поисковые
системы со специализированным интерфейсом конечного пользователя могут использоваться в качестве
надстроек над БД оперативных систем или ХД.
 Агрегированные показатели. Это сфера систем OLAP. Основные задачи: комплексный взгляд на
собранную в хранилище данных информацию, ее обобщение и агрегация, гиперкубическое представление
и многомерный анализ. Используются специальные многомерные СУБД или классические реляционные
технологии.
 Закономерности. Интеллектуальная обработка производится методами интеллектуального анализа данных
(ИАД или Data Mining). Задачи: поиск функциональных и логических закономерностей в накопленной
информации, построение объясняющих и/или прогнозирующих моделей и правил.
Обобщенная структура информационно-аналитической системы
Обобщенная структура информационно-аналитической системы, построенной на основе хранилища данных,
показана на рис. 4.6. Конечно, отдельные компоненты могут отсутствовать.
Генераторы запросов,
информационнопоисковые системы
(ИПС)
Информационные
системы руководителя
(ИСР)
Системы оперативной
аналитической
обработки данных
(OLAP)
Системы
интеллектуального
анализа данных (ИАД)
Витрины данных
Хранилище данных
Сбор, очистка и согласование данных из внешних источников
Транзакционные системы, источники данных
OLTP-система
OLTP-система
Рис. 4.6. Обобщенная структура информационно-аналитической системы
Вопросы для самопроверки
1. В чем сложности анализа данных из оперативных баз данных?
2. Какие общие требования к данным предъявляются при анализе данных?
3. Назовите основные компоненты Хранилищ Данных.
4. Что такое "тест FASMI"?
5. Дайте определение куба, измерения и меры. Приведите примеры.
6. Что такое "разрезание куба"?
7. Опишите роль меток, иерархий и уровней в структуре куба.
8. В чем выражается "многомерность" OLAP-приложений?
9. Зачем агрегаты данных иногда хранятся в явном виде?
10. Назовите основные способы хранения данных в системах OLAP.
11. Поясните разницу между статическими и динамическими информационно-аналитическими системами.
12. Перечислите основные отличающиеся характеристики статических и динамических информационноаналитических систем.
13. Перечислите особенности применения анализа детализированных данных, агрегированных показателей и
закономерностей.
14. Каковы основные компоненты информационно-аналитической системы?
15. Изложите основные идеи концепции оперативной аналитической обработки данных Кодда.
16. Что такое "прозрачность" и "доступность" системы OLAP?
17. Что такое "устойчивая производительность" системы OLAP?
18. Зачем система OLAP должна иметь клиент-серверную архитектуру?
19. Что такое "Равноправие измерений" в системе OLAP?
20. В чем суть требования "динамической обработки разреженных матриц" в системах OLAP?
21. Зачем в системах OLAP нужна поддержка многопользовательского режима?
22. В чем заключается "неограниченная поддержка кроссмерных операций"?
23. Как реализуется требование "интуитивного манипулирования данными" в системах OLAP?
24. Должно ли быть ограниченным количество измерений и уровней агрегации в системах OLAP? Почему?
25. Чем отличается гиперкуб от поликуба?
5. Хранилища данных
Хранилища данных являются основой систем анализа данных и СППР и строятся на основе многомерной
модели данных.
Определение хранилища
Это предметно-ориентированная, интегрированная, содержащая исторические данные,
совокупность данных, предназначенная для поддержки принятия управленческих решений.
неразрушимая
В хранилище помещаются данные из различных источников, а их описания – в репозиторий метаданных.
Структура хранилища данных
Перенос и
трансформация
данных
Оперативные
базы данных
Реляционное хранилище
Генерация отчетов
OLAP хранилище
OLAP-клиент
Репозиторий
Потоки данных
Потоки метаданных
Данные из оперативных систем не подходят для анализа, т.к. являются разрозненными, имеют различные
форматы, отражают только текущее время.
Облегченный вариант ХД – это витрины данных (Data Mart), т.е. это тематическое подмножество ХД.
Корпоративная информационно-аналитическая система может использовать:
 ХД – общекорпоративное
 витрины данных – на уровне подразделений
 аналитические системы на рабочих местах
В основе концепции ХД лежит идея разделения данных для оперативной обработки и для анализа.
Основные свойства ХД
 Предметная ориентация. ХД объединяет информацию из разных ОИД (оперативных источников данных),
т.е. информацию, отражающую разные точки зрения на эту предметную область. Хранятся только нужные
для анализа данные.
 Интеграция – единый формат данных.
 Поддержка хронологии – хронология изменения показателей предметной области. Поэтому данные в ХД
соответствуют последовательным интервалам времени.
 Неизменяемость – данные не удаляются (как устаревшие) и не модифицируются.
Виртуальное ХД
Данные не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются во время
запроса в ОП. Это позволяет минимизировать объем памяти носителя (избежать избыточности), работать с
текущими, детализированными данными.
Недостатки:
 Данные в ОИД – нормализованы, поэтому при выполнении запроса приходится объединять много таблиц.
Отсюда – большое время выполнения запроса.
 На один и тот же аналитический запрос может быть получено несколько вариантов ответа. Т.к. ОИД имеют
различные форматы и кодировку данных, а также не синхронизированные моменты обновления данных.
 Главный недостаток – невозможность получения данных за долгий период времени.
Требования к ХД и их организация
Требования:
 Интеграция данных из разнородных источников в распределенной среде.
 Хранение и обработка очень больших объемов информации.
 Наличие многоуровневых справочников метаданных.
 Повышенные требования к безопасности.
Данные в ХД:
 детальные
 агрегированные
 метаданные
В процессе работы менее нужные данные можно помещать в архив (более медленный доступ к устройствам).
Детальные данные разделяются на измерения – наборы данных, описывающие события (города, товары,
люди) и факты – сущность события (количество проданного товара).
Агрегированные получают суммированием детальных числовых данных по определенным измерениям. В
зависимости от возможности агрегировать различают:
 аддитивные – числовые фактические данные, которые могут быть просуммированы по всем измерениям
 полуаддитивные - числовые фактические данные, которые могут быть просуммированы по некоторым
измерениям
 неаддитивные – не могут быть просуммированы
Агрегированные данные редко увеличивают избыточность и размер ХД. Поэтому те данные, к которым
обращаются редко, могут храниться не агрегированными, тогда над ними будут производиться вычисления в
процессе выполнения запроса.
Информация о содержащихся в ХД данных – это метаданные (что – описание объектов; кто – описание
пользователей; где – место хранения; когда – описание времени; почему – причины). Они хранятся в
репозитории с удобным пользовательским интерфейсом. Поток метаданных – поток информации об объектах
предметной области.
Самый большой поток – входной. Данные очищаются и обогащаются новыми атрибутами (может быть
объединение с внешними данными – текстовые файлы, Е-мэйл, электронные таблицы).
60% затрат при разработке ХД связаны с переносом данных. Процесс переноса включает в себя:
 извлечение
 преобразование
 загрузку
Такой процесс называется ETL-процессом (E - extraction, T - transformation, L – loading). Его выполняют ETLсистемы.
Этапы ETL-процесса
Схема ETL-процесса
Извлечение данных
Два способа извлечения данных:
1. Из структур хранения информации – файлов, электронных таблиц, БД (вспомогательными программными
средствами). Достоинства:
a) отсутствие необходимости расширять OLTP-систему
b) данные могут извлекаться с учетом потребностей процесса переноса
2. Выгрузка данных средствами OLTP-систем в промежуточные структуры. Достоинства:
a) Возможность использовать средства OLTP-систем, адаптированные к структурам данных
b) Средства выгрузки изменяются вместе с изменениями OLTP-систем и ОИД
c) Возможность выполнения первого шага преобразования данных за счет определенного формата
промежуточной структуры хранения
Преобразование данных
Преобразование данных включает процедуры:
 Обобщение данных (aggregation) – это замена многочисленных детальных данных относительно
небольшим числом агрегированных данных.
 Перевод значений (value translation). В ОИД данные часто хранятся в закодированном виде, чтобы
сократить избыточность и память. Например, названия городов, товаров могут храниться в сокращенном
виде. Перед загрузкой в ХД закодированные данные обычно заменяют более понятными описаниями.
 Создание полей (field derivation). При этом создается новая информация. Например, в ОИД есть одно поле
для указания товара, второе – для цены экземпляра. Для исключения операции вычисления стоимости
всех товаров можно создать специальное поле для хранения стоимости во время преобразования.
 Очистка данных (cleaning) – выявление и удаление ошибок и несоответствий в данных с целью улучшения
их качеств. Например, в файлах БД могут быть ошибки при вводе, отдельная информация может быть
утрачена, могут присутствовать «загрязненные» данные и т.д. Очистка применяется также для
согласования атрибутов полей так, чтобы они соответствовали атрибутам БД назначения.
Очистка данных
Основные проблемы очистки можно классифицировать по следующим уровням:
1. Уровень ячейки таблицы. К ошибкам в ячейке БД можно отнести:
a) орфографические ошибки (опечатки) при вводе
b) отсутствие данных (незаполненные ячейки, содержащие значение NULL)
c) фиктивные значения – введенные оператором, но не имеющие смысла (например, почтовый индекс
99999, возраст клиента 999 лет и другие)
d) логически неверные значения (например, в поле «город» находится значение «Россия»)
e) закодированные значения – сокращенная запись или кодировка реальных данных для уменьшения
занимаемого места
f) составные значения – содержащие несколько логических данных в одной ячейке таблицы. Это
возможно для строгого или текстового форматов. Кроме того, может отсутствовать формат записи в
такие поля.
2. Уровень записи. На этом уровне возникает проблемы противоречивости значений в разных полях записи,
описывающей один объект. Например, «возраст»=22, «дата рождения»=12.12.86.
3. Уровень таблицы БД. Это проблемы, связанные с несоответствием информации, хранящейся в таблице
и относящейся к разным объектам. Это может быть:
a) нарушение уникальности – значения, соответствующие уникальным атрибутам разных объектов
являются одинаковыми
b) отсутствие стандартов на формат записи – из-за этого может быть дублирование данных или их
противоречивость.
4. Уровень одиночной БД. Проблемы нарушения целостности БД.
5. Уровень множества БД. Проблемы неоднородности структур БД и хранящейся в них информации:
6. различие структур: различие наименований полей, типов, размеров
7. в разных БД есть одинаковые наименования разных атрибутов
8. одинаковые данные представлены по-разному
9. разная классификация элементов
Не все проблемы могут быть устранены при очистке. Кроме того, данные, достоверность которых не влияет на
процесс принятия решений, могут остаться неочищенными.
Этапы очистки:
1. Выявление проблем в данных. Анализ данных производиться 2 методами:
a) Профайлинг – грубый анализ отдельных атрибутов данных (тип, длина, спектр значений, дискретные
значения и их частота, уникальность, наличие NULL-значений).
b) Data Mining – выполняет группировку, обобщения, поиск ассоциаций, последовательностей, то есть
помогает найти специфические модели в больших наборах данных.
2. Определение правил очистки данных. Сначала устраняются проблемы отдельных источников данных.
Потом выполняется интеграция данных и устранение проблем множественности источников (на этом этапе
должна быть выработаны правила, часть представлена ПО очистки).
3. Тестирование правил. Правила должны оцениваться на копиях данных. Этапы определения правил, и их
тестирование могут выполняться итерационно.
4. Непосредственная очистка данных. Преобразования выполняются в два приема в соответствии с
определенными ранее правилами. Сначала – проблемы, связанные с отдельными источниками, а затем –
с многоженствами БД.
5. Замена загрязненных данных очищенными. Данные ХД имеются в подсистемах анализа данных. От вида
анализа зависит реализация структур.
Хранилища данных и OLAP
OLAP-система состоит из:
 Источника данных (сервер, поставляющий данные; хранилище БД, таблицы)
 OLAP-сервера (подготавливает данные)
 OLAP-клиенты (пользовательский интерфейс)
Сервер может иметь архитектуру:
 MOLAP (Multidimensional OLAP) - и детальные данные, и агрегаты хранятся в многомерной БД. В этом
случае получается наибольшая избыточность, так как многомерные данные полностью содержат
реляционные.
 ROLAP (Relational OLAP) - детальные данные остаются там, где они "жили" изначально - в реляционной
БД; агрегаты хранятся в той же БД в специально созданных служебных таблицах.
 HOLAP (Hybrid OLAP) - детальные данные остаются на месте (в реляционной БД), а агрегаты хранятся в
многомерной БД.
Многомерный OLAP (MOLAP)
Данные организованны в виде упорядоченных многомерных массивов (кубов).
Основное назначение многомерных СУБД (МСУБД) – реализация систем, ориентированных на динамический,
многомерный анализ исторических данных (и текущих). Они ориентированы на обработку произвольных
запросов. Поэтому проектирование МБД начинается с определения вопросов, с которыми конечные
пользователи хотели бы обратиться к системе.
Например, для ответа на вопрос: «Какие два варианта скидок наиболее эффективны в западном регионе в
летний период при продаже «Жигулей» на основе данных за последние 10 лет», в БД должны быть данные об
объеме продаж по 4 измерениям:
1. Год/Квартал/Месяц/Неделя/День/Счет
2. Страна/Регион/Филиал/Менеджер
3. Фирма-производитель/Завод-изготовитель/Модель-автомобиль
4. Тип скидки
Выберем уровень детализации и агрегации:
1. День (365х10=3650 значений)
2. Менеджер (300 значений)
3. Модель (100 значений)
4. Тип скидки (4 значения)
Получим куб, состоящий из 438000000 ячеек. В основе используемого в МСУБД способа хранения лежит
предположение, что «пустые» не хранятся. Значения показателей хранится в виде множества логически
упорядоченных блоков (массивов), имеющих фиксированную длину. Блок – минимальная индексированная
единица. Блоки с полностью неопределенными значениями не хранятся. Реальные значения (на сегодняшний
день) могут составлять приблизительно 0,25% всех ячеек (365х30х10х1).
Подход к агрегации влияет и на размер БД и на время выполнения запросов. Их значения должны быть
оптимальными.
Структура данных для этого уровня детализации (агрегации).
Измерения: DAY – день, MANAGER – менеджер, MODEL_CAR – модель, FIRMA_CAR – фирма-производитель,
DEPARTMENT – подразделение (филиал), REGION –регион, MONTH – месяц, YEAR – год, TIP_DISCOUNT – тип
скидки.
Показатели (меры): TOTAL_COST – объем продаж, INT_COST – себестоимость проданного авто, QOANTITY –
количество проданного авто, PROFIT – доход, WORK_TIME – количество рабочих часов.
Достоинства МСУБД:
 точно моделируют бизнес-данные
 быстрый доступ без SQL-запросов (на 1,2 порядок)
 содержат заранее рассчитанные сводные данные
Ограничения:
 не позволяют работать с большими БД (только десятки Гб)
 неэффективно используют внешнюю память, так как данные хранятся блоками в упорядоченном виде, и
непосредственные значения не всегда удаляются полностью
 не поддерживают репликацию данных
Условия применения:
 небольшой объем данных (<нескольких Гб)
 набор измерений стабилен
 время ответа системы на запрос является критическим параметром
 требуется использовать сложные строенные функции над ячейками гиперкуба
Реляционный OLAP (ROLAP)
ROLAP-серверы используют реляционные БД. Основными составляющими таких схем
ненормализованная таблица фактов (Fact Table) и множество таблиц измерений (Dimension Tables).
являются
Таблица фактов содержит сведения об объектах или событиях, совокупность которых будет анализироваться.
Типы фактов могут быть:
 факты, связанные с транзакциями (Transaction facts), основаны на событиях (например, телефонный
звонок)
 факты, связанные с моментальными снимками (Snapshot facts), основаны на состоянии объекта (например,
банковского счета) в определенные моменты времени (например, объем продаж за день)
 факты, связанные с элементами документа (Line-item facts), основаны на конкретном документе и содержат
подробную информацию о его элементах
 факты, связанные с событиями или состоянием объекта (Event or state facts), представляют возникновение
события без подробности о нем (факт продажи или ее отсутствия)
Таблица фактов содержит уникальный составной ключ, объединяющий первичные ключи таблицы измерений.
При этом как ключевые, так и некоторые не ключевые поля должны соответствовать измерениям гиперкуба.
Кроме этого fact table содержит одно или несколько числовых полей, на основании которых в дальнейшем будут
получены агрегатные данные.
Для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (т.е.
соответствующие членам нижних уровней иерархии измерений).
Таблицы измерений содержат неизменяемые или редко изменяемые данные. Часто это – по одной записи для
каждого члена нижнего уровня в иерархии содержат одно описательное поле (имя члена измерения) и
целочисленное ключевое поле.
Если измерение, соответствующее таблице, содержит иерархию, то такая таблица может содержать поля,
указывающие на «родителя» данного члена в этой иерархии. Каждая таблица измерений должна находится в
отношении1:М с таблицей фактов.
Скорость роста таблиц измерений должна быть незначительна по сравнению со скоростью роста таблицы
фактов (новая запись в таблице измерений – «товары»; только при появлении нового товара).
При большом числе независимых измерений необходимо поддерживать множество таблиц фактов,
соответствующих каждому возможному сочетанию выбранных в запросе измерений.
Увеличение числа таблиц фактов в базе данных является следствием: (а) множественности уровней различных
измерений; (б) факты имеют разные множества измерений. Поэтому, необходимо поддерживать множество
таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений. Это также
приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы
звезды из внешних источников и сложностям администрирования. Частично решают эту проблему расширения
языка SQL (операторы "GROUP BY CUBE", "GROUP BY ROLLUP" и "GROUP BY GROUPINGSETS"). Также,
рекомендуется создавать таблицы фактов не для всех возможных сочетаний измерений, а только для тех,
значения ячеек которых не могут быть получены с помощью последующей агрегации более полных таблиц
фактов.
Таким образом, если многомерная модель реализуется в виде реляционной базы данных, следует создавать
длинные и "узкие" таблицы фактов и сравнительно небольшие и "широкие" таблицы измерений. Таблицы
фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их
многомерный базис измерений. Часть информации можно получать с помощью динамической агрегации данных,
распределенных по незвездообразным нормализованным структурам.
Достоинства:
 Анализ производится непосредственно над данными хранилища (т.к. большинство корпоративных
хранилищ реализуются средствами РСУБД).
 Позволяют динамически изменять структуру измерений без физической реорганизации БД.
 Т.к. основная нагрузка при вычислении на сервере, где выполняются сложные аналитические SQLзапросы, то меньше требования к клиентским установкам.
 Более высокий уровень защиты прав доступа
 Возможность работы с очень большими базами.
Недостатки:
 Ограничения функциональных значений.
 Меньшая производительность.
 Если факты имеют разные множества измерений, их удобнее хранить в нескольких таблицах. Кроме того, в
разных запросах пользователей может интересовать только часть возможных измерений. Это приводит к
неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы
«звезда» из внешних источников и сложностям администрирования. Для преодоления этого можно
использовать специальное расширение для SQL (оператор GROUP BY CUBE и ключевое слово ALL) и
создавать таблицы фактов не для всех возможных сочетаний измерений, а для тех, значения которых не
могут быть получены с помощью последующей агрегации ячеек других таблиц фактов.
В любом случае следует создавать длинные и «узкие» таблицы фактов и сравнительно небольшие и «широкие»
таблицы измерений.
Распространены две основные схемы реализации многомерного представления
реляционных таблиц: схема «звезда» и «снежинка».
данных с помощью
Схема "звезда"
В классическом варианте, типа "звезда" (star schema) предполагает наличие одной большой ненормализованной
фактологической таблицы, с которой соотнесено несколько относительно небольших справочных таблиц. Идея
заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу,
индексируемую множественным ключом, составленным из ключей отдельных измерений. Каждый луч схемы
звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению.
Consumenrs
PK
Period
КлючПотребитель
PK
Описание
Описание
Год
Квартал
Месяц
День
Sales
FK3
FK1
FK4
FK2
КлючПотребитель
КлючПродукт
КлючПериод
КлючПоставщик
Количество
Цена
Стоимость
Products
PK
КлючПериод
Providers
КлючПродукт
PK
Описание
КлючПоставщик
Описание
Рис. 5.1. Пример схемы "звезда"
Схема "снежинка"
Схема "созвездие" (fact constellation schema) и схема "снежинка" (snowflake schema). Используется в сложных
задачах с иерархическими измерениями. Здесь отдельные таблицы фактов создаются для возможных
сочетаний уровней обобщения различных измерений. Это позволяет добиться лучшей производительности, но
часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных.
Consumenrs
City
PK
КлючПотребитель
PK
КлючГород
FK1
КлючГород
Описание
FK1
КлючРегион
Описание
Sales (consumers)
FK1
Sales (cities)
КлючПотребитель
Количество
Цена
Стоимость
FK1
КлючГород
Количество
Цена
Стоимость
Regions
PK
КлючРегион
Описание
Sales (consumers)2
FK1
КлючРегион
Количество
Цена
Стоимость
Рис. 5.2. Пример схемы "снежинка" (фрагмент для двух измерений)
Consumenrs
PK
Regions
КлючПотребитель
PK
Описание
Описание
Sales (consumers)
FK1
КлючПотребитель
Количество
Цена
Стоимость
КлючРегион
FK1
FK2
Sales (cities)
Sales (consumers)2
КлючПотребитель
КлючРегион
Количество
Цена
Стоимость
FK1
КлючРегион
Количество
Цена
Стоимость
Рис. 5.3. Таблицы фактов для разных сочетаний измерений в запросе
OLAP-клиент
Это может быть:
 электронная таблица MS Office
 специальные приложения
 Интернет-приложения
Сложность или малоэффективность клиента может не позволить использовать все возможности OLAP-сервера.
Стандартные клиентские приложения обеспечивают стандартный интерфейс для прикладных задач (например,
финансовых). Реализуются инструментом запросов (генераторами отчетов). Имеют простой графический
интерфейс, позволяют пользователю создавать отчеты перемещением объектов в него. Можно создавать одну
диаграмму, а затем выполнять с ней различные манипуляции. Специальные приложения имеют большие
функциональные возможности, чем генераторы запросов.
Вопросы для самопроверки
1. Откуда появилась необходимость в Хранилищах Данных?
2. Каковы отличия характеристик данных в оперативных и аналитических системах?
3. Перечислите основные требования к данным Хранилищ Данных.
4. Как соотносятся между собой концепции Хранилищ Данных и анализа данных?
5. Почему неоднородность программной
проектировании Хранилищ Данных?
среды
является
важным
фактором,
учитываемым
при
6. Почему распределенность данных является важным фактором, учитываемым при проектировании
Хранилищ Данных?
7. Почему использование метаданных конечными пользователями является важным фактором, учитываемым
при проектировании Хранилищ Данных?
8. Почему защита данных является важным фактором, учитываемым при проектировании Хранилищ Данных?
9. Почему большие объемы хранимых
проектировании Хранилищ Данных?
данных
являются
важным
фактором,
учитываемым
при
10. Назовите причины, снижающие эффективность РСУБД при их использовании для создания Хранилищ
Данных.
11. Что из себя представляет схема "звезда" в структурах реляционных баз данных? Зачем она нужна?
12. Когда бесполезны индексы при оптимизации доступа к данным в Хранилищах Данных?
13. Что такое "витрины данных"? В чем выгоды их использования?
14. Каковы основные достоинства MOLAP и недостатки ROLAP?
15. Каковы основные достоинства ROLAP и недостатки MOLAP?
6. Технологии проектирования КИС
Что такое описание проекта?
Работа с любой сложно системой требует ее описания. Поэтому для успешной реализации ИС ее проект должен
быть хорошо описан. Адекватное описание – полное и непротиворечивые функциональная и информационная
модели ИС.
Неформальные подходы
Неформальное моделирование выполняется всегда. До недавнего времени (и часто и сейчас) используются
интуиция, искусство, практический опыт, неформализованные методы, экспертные оценки. Это, конечно, не
идеально. А с учетом того, что потребности пользователей постоянно изменяются и уточняются –
использование только неформальных методов при проектировании, как правило, не приводит к положительному
результату.
Структурные методы
Появились в 70-80 гг. (использование различных формальных представлений информационных и
функциональных моделей, в том числе схем, диаграмм, таблиц). Позволяют участвовать пользователям в
разработке систем. Однако их применение сдерживалось использованием "ручных" технологий проектирования
ИС.
Недостатки "ручных" технологий
При ручной обработке данных использование структурных методов невозможно. Основная проблема – внесение
изменений в документацию. Общие недостатки ручных технологий:
 Неадекватная спецификация требований.
 Неспособность обнаружить ошибки в решении.
 Низкое качество документации.
 Затяжной цикл проектирования.
Таким образом, требовались новые технологии.
CASE-средства и технологии
Термин "CASE" расшифровывается как Computing Aided Software/System Engineering.
Первоначально термин относился только к программному обеспечению, но потом и сейчас – к ИС в целом.
CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
Предпосылки появления CASE-средств
 Восприимчивость современных специалистов к концепциям модульности, структурного и объектного
программирования.
 Высокопроизводительная техника (обработка больших объемов информации, в частности графических
данных).
 Сетевые технологии (обеспечивают взаимодействие групп разработчиков).
CASE-технология – методология проектирования ИС и набор инструментальных средств, позволяющих
в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах
разработки и сопровождения ИС и разрабатывать на ее основе приложения в соответствии с
информационными потребностями пользователя.
Особенности внедрения CASE
По результатам некоторых опросов CASE-системы используют более, чем половина фирм, занимающихся
внедрением ИТ для более 1/3 проектов.
Однако:
 Использование CASE-технологий не обязательно дает немедленный эффект.
 Затраты на внедрение много больше затрат на приобретение необходимых CASE-средств.
 CASE-технологии обеспечивают выгоду только после успешного внедрения.
При этом определение действительного эффекта от внедрения CASE-средств усложняется таким проблемами,
как: недостаток опыта их применения, отсутствие детальных критериев успешности внедрения, разная степень
внедряемости CASE-средств, разная степень интегрируемости с другими ИТ, используемыми на предприятии.
Ключевые факторы успеха внедрения CASE
 Технология – понимание ограниченности существующих возможностей и способность принять новую
технологию.
 Культура – способность принять новые процессы и взаимоотношения между разработчиками и
пользователями.
 Управление – четкое руководство и организованность по отношению к наиболее важным этапам и
процессам внедрения.
При отсутствии готовности предприятия – провал во внедрении CASE, независимо ни от чего.
Замечание: Несмотря ни на что, одно преимущество от использования CASE-средств присутствует практически
всегда. Это улучшение дисциплины проектирования. Хотя, конечно, это требует дополнительных усилий
(особенно от разработчиков).
Общие выводы
Выгоды использования
документирование.
CASE-технологий:
производительность,
качество,
соблюдение
стандартов,
Сдерживающие факторы: долгосрочные затраты на проектирование и эксплуатацию, быстрое моральное
старение средств, затраты на обучение и повышение квалификации.
Вопросы для самопроверки
1. Из каких основных частей состоит адекватное описание проекта ИС?
2. В чем выражаются неформальные подходы к проектированию ИС?
3. Перечислите недостатки "ручных" технологий проектирования ИС?
4. Дайте определение понятия "CASE-технология".
5. Перечислите особенности внедрения CASE-технологий.
6. Каковы основные факторы успеха внедрения CASE- технологий.
7. Каковы основные сдерживающие факторы при внедрении CASE- технологий.
8. Перечислите выгоды от использования CASE-технологий.
7. Основы методологии проектирования КИС
Жизненный цикл КИС
Жизненный цикл (ЖЦ) – одно из базовых понятий методологии проектирование КИС.
ЖЦ КИС – процесс от момента принятия решения о создании ИС до момента полного изъятия ее из
эксплуатации.
Структура ЖЦ
 Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение программного и
информационного обеспечения).
 Вспомогательные процессы – обеспечивают выполнение основных (документирование, конфигурирование,
обеспечение качества, аттестация, верификация).
 Организационные процессы (управление проектами, создание инфраструктуры проекта, обучение).
Все процессы носят итерационный характер.
Модели ЖЦ
Определение модели ЖЦ
Модель ЖЦ - это структура, определяющая последовательность выполнения и взаимосвязи процессов,
действий и задач на протяжении ЖЦ.
Каскадная модель
Ранее (да и сейчас) в основном применялась каскадная модель разработки ИС:
Особенность: разбиение на этапы, каждый следующий этап начинается после завершения предыдущего.
Достоинства:
 На каждом этапе законченный результат (функционирующее ПО, документация).
 Хорошо планируемые работы (по времени и по затратам).
Эта модель может быть применена тогда, когда можно точно определить требования на каждом этапе. Поэтому
на самом деле чаще применяется модель с промежуточным контролем.
Каскадная модель с промежуточным контролем
Основной недостаток: существенное запаздывание с результатом. ИС может морально устареть еще до
завершения разработки. Кроме этого, изменения можно вносить только после завершения этапа (в процессе
исполнения этапа это делать, как правило, сложно).
Сложности работы по каскадной модели
Одним из главных недостатков каскадной модели является необходимость возврата назад на пройденные
этапы.
Во время анализа проекта необходимо:
 Обсудить с пользователями и исследовать бизнес-процессы.
 Надо, чтобы пользователи согласились с результатами обследования (хотя они могут и не ознакомиться с
ними до конца).
 Полностью определить все требования к системе.
Обычно таким способом удается собрать около 80% требований к системе.
В течение проектирования необходимо:
 Определить архитектуру будущей системы (где будут установлены программы и какая аппаратура нужна
для достижения приемлемой производительности).
 Обсуждать появляющиеся проблемы с пользователями, что выразится в появлении новых требований к
системе.
Как следствие – возврат к анализу.
Во время реализации (написания программного кода) необходимо:
 Пересмотреть некоторые из принятых ранее решений, так как их невозможно осуществить.
 Уточнить требования, которые не были достаточно детализированы и, как следствие, их реализация
некорректна.
В результате: "Да, это то, что я просил, но не то, чего я хочу!".
Таким образом, проблемы состоят в следующем:
1. Бизнес меняется очень быстро. Разработчики должны поспевать за этими изменениями.
2. Пользователи не всегда могут сказать, чего они хотят. Работа стала для них настолько привычной, что ее
уже трудно описать.
3. Пользователи не всегда понимают команду разработчиков.
4. Точное следование этапам проекта (каскадное проектирование).
Поэтому используется спиральная модель ЖЦ.
Спиральная модель
Главная задача - как можно скорее показать пользователям результат. Основной акцент при использовании
этой модели делается на анализ и проектирование.
Основная проблема – определение оптимального момента перехода на следующий этап. Важно отметить, что
можно переходить на следующий этап, не дожидаясь полного завершения работы на текущем.
Общие требования к методологии и технологии проектирования КИС
Схема взаимосвязи Методология -> Технология -> Инструмент:
Схема технологической операции проектирования
Требования к методологии и технологии проектирования ИС:
 Поддержка полного ЖЦ.
 Гарантированное достижение целей (с заданным качеством и в установленные сроки).
 Возможность выполнения крупных проектов в виде подсистем (декомпозиция проектов).
 Возможность работ по проектированию отдельных подсистем небольшими группами (3-7 чел.).
 Минимизация времени разработки подсистем.
 Возможность ведения версий проекта и автоматического получения документации.
 Независимость проектных решений от средств реализации ИС (например, СУБД).
 Поддержка CASE-средств, обеспечивающих автоматизацию процессов.
Стандарты
Стандарты проектирования
 Набор модулей (диаграмм) на каждой стадии и степень их детализации.
 Правила организации проектных решений (терминология, именование, наборы атрибутов, вид графических
элементов и т.д.).
 Требования к конфигурации рабочих мест (настройка ОС, CASE, проекта).
 Механизм обеспечения совместной работы (регламентация обмена, механизм фиксации общих объектов).
Стандарт оформления проектной документации
 Оформление.
 Правила подготовки, согласования, утверждения.
 Настройка издательской системы.
 Настройка CASE-средств.
Стандарт интерфейса пользователя
 Экраны.
 Клавиатура.
 Help.
 Сообщения.
 Отработка реакции пользователя.
Методология RAD
Методология RAD (Rapid Application Development – быстрое проектирование приложений) - это пример
современной методологии проектирования, основанной на спиральной модели ЖЦ ИС. Используется для
небольших проектов для конкретного заказчика. Не подходит для следующих ИС:
 Сложные системы (оборонные, для космических исследований, и т.д. – эти системы требуют тщательного
проектирования и высочайшего качества).
 Системы реального времени (в этих ИС должна быть сразу разработана работоспособная версия).
Оценка потребных ресурсов зависит от сложности проектируемой ИС. Сложность оценивается по количеству
функциональных элементов (экранов, файлов, сообщений, отчетов и т.д.). Такая оценка не зависит от языка
программирования.
Приняты следующие оценочные показатели для расчета количества разработчиков ИС: <1000 ф.э. - 1 чел.;
1000-4000 – команда(3-5 чел.); >4000 - несколько команд по 4000 на каждую.
Основные принципы RAD:
 Разработка итерациями.
 Необязательность полного завершения работ на этапе.
 Обязательность вовлечения пользователей.
 Необходимость CASE-средств.
 Необходимость использования генераторов кода (заготовок).
 Использование прототипирования.
 Тестирование и развитие одновременно с разработкой.
 Немногочисленная, хорошо управляемая группа (3-10 чел.).
 Грамотное руководство разработкой, планирование, контроль.
 Ограниченный срок разработки (2-6 месяцев).
Сущность структурного подхода к разработке КИС
Структурный подход должен применяться при проектировании и разработке относительно сложных систем.
Заключается в декомпозиции ИС на автоматизируемые функции: подсистемы, функции, подфункции, задачи.
Достоинство: увязка составных частей.
Недостаток: чтобы учесть горизонтальные связи, ИС нужно разрабатывать фронтально.
Базовые принципы:
Главные: (а) Разбиение и (б) Иерархическое упорядочивание.
Другие принципы:
 Абстрагирование (выделение существенных аспектов).
 Формализация (строгая методология).
 Непротиворечивость (обоснованность и согласованность).
 Структурирование данных (организация).
При проектировании ИС используется 2 группы моделей:
 Функциональные (моделирование процессов). В данном курсе рассматривается модель SADT (Structured
Analysis and Design Technology) и UML (Unified Model Language).
 Информационные (моделирование данных). В данном курсе рассматриваются Data Flow Diagram (DFDмодель) и Entity Relationship Diagram (ER-модель).
Вопросы для самопроверки
1. Что такое "жизненный цикл ИС" и какова его структура?
2. Перечислите основные известные Вам модели ЖЦ ИС?
3. Сформулируйте достоинства и недостатки каждой известной Вам модели ЖЦ ИС.
4. Что необходимо для выполнения технологической операции проектирования?
5. Каковы основные требования к методологии и технологии проектирования ИС?
6. Какие основные виды стандартов проектирования Вы знаете?
7. Перечислите компоненты, входящие в состав стандарта каждого известного Вам вида.
8. Определите область применения методологий проектирования RAD.
9. Каковы основные принципы методологии проектирования RAD?
10. Назовите базовые принципы структурного подхода к проектированию ИС.
8. Моделирование КИС
Методология функционального моделирования IDEF0. Общие сведения
Эта методология функционального моделирования разработана в рамках программы Integrated Computer Aided
Manufacturing (ICAM) и получила название ICAM Definition (IDEF0). Представляет собой совокупность правил и
процедур для построения функциональной модели, то есть производимых объектом действий и связей между
этими действиями.
Основные концепции IDEF0
1. Графическое представление (модель состоит из блоков, объединенных в иерархические диаграммы).
2. Строгость и точность. Некоторые правила: 3-6 блоков на каждом уровне, нумерация, уникальность меток,
разделение входов и управлений (роли данных).
3. Отделение организации от функции (исключение влияния организационной структуры на функциональную
модель).
Типы связей между функциями
Типы связей между функциями (перечислены в порядке увеличения важности):
Случайные – связи малы или вообще отсутствуют.
Логические связи – функции находятся в общем классе или типе. Например, тип функции – "Редактировать
документы", а функции в логической связи – "Редактировать ведомость" и "Редактировать ордер".
ВременнАя связь – данные несколькими функциями используются одновременно, при этом происходит
параллельное выполнение функций.
Процедурная связь – функции выполняются в течение одной и той же части процесса. Например, "Планировать
А", "Планировать Б", "Согласовать А и Б".
Коммуникационная связь – функции используют одни и те же входные данные или одни и те же выходные
данные.
Последовательная связь – выход одной функции служит входом другой. Связь важная, т.к. формируются
причинно-следственные отношения.
Функциональные связи – все связанные функции влияют на выполнение одной и только одной функции:
С=g(B) = g(f(A))
Примеры диаграмм IDEF0
Блок:
Обратная связь:
Механизм:
Иерархия диаграмм:
Вопросы для самопроверки
1. Почему для построения функциональных моделей удобно использовать графическое представление
элементов модели?
2. Почему в функциональных моделях IDEF0 не принято отображать организационную структуру предприятия?
3. Зачем используется иерархическая вложенность диаграмм?
4. Перечислите известные вам типы связей между функциями и приведите примеры.
Основы методологии моделирования потоков данных. Общие сведения
Базовые понятия моделирования
Информационную модель информационной системы (ИС) можно представить как иерархию диаграмм потоков
данных (Data Flow Diagram или DFD), состоящих из блоков вида:
Основные элементы DFD:
a. Внешние сущности.
b. Системы / подсистемы.
c. Процессы.
d. Накопители данных.
e. Потоки данных.
Внешняя сущность. Это материальный предмет или физическое лицо, представляющее собой источник
информации. Например: заказчик, поставщик, склад, клиент.
Обозначение:
Заказчик
Система и подсистемы. Для систем/подсистем используется следующие правила обозначения, которые могут
иметь иерархическую структуру:
1
- идентификатор блока
<имя>
- наименование
<имя ИС>
- имя организационной единицы
Процесс. Преобразование входных данных в выходные в соответствии с некоторым алгоритмом.
Обозначение процесса:
1
- идентификатор блока
<имя>
- наименование
<физическая реализация>
- кто выполняет (подразделение, аппарат, программа, человек)
Любые наименования процессов следует начинать недвусмысленным глаголом в неопределенной форме:
"Ввести информацию о клиентах", "Проверить кредитоспособность клиента". Слова "обработать",
"модернизировать" и т.п. требуют дальнейшего анализа.
Накопитель данных. Абстрактное устройство для хранения информации, которую можно поместить в
накопитель данных и извлечь оттуда.
D1
Получаемые счета
Накопитель данных (НД) есть прообраз будущей базы данных.
Поток данных. Определяет информацию, передаваемую через некоторое соединение от источника к
приемнику. Примеры: дискета, кабель, почта.
Построение иерархии диаграмм потоков данных
Основные правила построения иерархических диаграмм DFD:
1) Правило балансировки – детализирующая DFD в качестве внешних источников (приемников) данных может
иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных и т.п.), с
которыми имеют связь детализируемые подсистема и процесс.
2) Правило нумерации – иерархическая нумерация. Например, 1, 1.1, 1.1.1.
Результат построения DFD: иерархический набор диаграмм потоков данных в виде мини-спецификаций.
Критерии корректности мини-спецификаций:
1) 2-3 потока входных и выходных данных.
2) Возможность описания преобразования данных процессом в виде последовательного алгоритма.
3) Выполнение процессом единственной логической функции преобразования данных.
4) Объем текстового описания – 20-30 строк.
Особенности описания потоков и накопителей данных
1) Альтернатива (использование только одного из перечисленных элементов).
2) Условное вхождение элемента (может входить, а может нет).
3) Итерация (элемент входит в структуру заданное количество раз).
4) Непрерывные и дискретные данные.
5) Единицы измерения (для непрерывных) или допустимые значения (для дискретных).
Верификация модели DFD
Полнота – все объекты описаны и детализированы.
Согласованность – все поступающие данные должны быть считаны откуда-то, а считанные данные записаны
куда-либо.
Пример иерархии диаграмм DFD
Начальная диаграмма:
Один из следующих уровней:
Вопросы для самопроверки
1. Назовите основные элементы диаграммы потоков данных.
2. Дайте определение понятия "процесс" и приведите примеры.
3. Что такое "поток данных"?
4. Какие правила действуют при построении иерархии диаграмм потоков данных?
5. Как проверить правильность диаграммы потоков данных?
Моделирование данных. Общие сведения
Базовые понятия
Цель – обеспечение разработчика ИС концептуальной схемой БД в форме одной модели или нескольких
локальных моделей, которые (относительно легко) могут быть отображены в любую систему БД.
Наиболее распространенным средством моделирования являются ER-модели (впервые предложены Ченом).
Сущность
(Entity)
–
реальный
или
воображаемый
объект,
имеющий
существенное
значение
для
рассматриваемой предметной области.
Свойства сущности:
1) Уникальное имя. К одному имени всегда должна применяться одна и та же интерпретация.
2) Имеет один или несколько атрибутов, которые либо принадлежат сущности либо наследуются через связь
(человек – Иванов).
3) Имеет один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности.
4) Может иметь любое количество связей с другими сущностями.
Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой
предметной области. Каждый экземпляр одной сущности ассоциирован с произвольным (может быть нулевым)
количеством экземпляров другой сущности.
Атрибут – любая характеристика сущности, значимая для рассматриваемой предметной области.
Назначение атрибута – квалификация, идентификация, классификация, количественная характеристика,
выражение состояния. Атрибут определяется типом и значением. Один экземпляр сущности имеет по одному
значению каждого атрибута.
CASE-метод Баркера
Этот метод есть развитие ER-модели. Метод рассмотрен на примере компании по торговле автомобилями.
Шаг 1. Извлечение информации из интервью и выделение сущностей.
Шаг 2. Идентификация связей.
Выделяются сущности-родители и сущности-потомки. Последние могут существовать только при наличии
первых. Связи может быть дадено имя (не обязательно уникальное). Имена даются со стороны родителя и со
стороны потомка.
Например, связи "Продавец – контракт":
1) Продавец получает вознаграждение за контракт
2) Контракт инициируется продавцом
Изображение связей:
Обязательная
Необязательная
1:М
Шаг 3. Идентификация атрибутов.
Полная идентификация – только для атрибутов данной сущности. В противном случае для идентификации
используются атрибуты сущности родителя.
Виды атрибутов:
1) обязательный или нет.
2) описательный или ключевой.
3) уникальный идентификатор (один или несколько атрибутов, уникально идентифицирующих экземпляр
сущности).
В результате получаем:
Дополнительные конструкции модели данных
Подтипы и супертипы. Одна сущность является обобщающим понятием для группы подобных сущностей.
Взаимно исключающие связи. Каждый экземпляр сущности участвует только в одной связи из группы связей.
Рекурсивная связь.
Неперемещаемые связи (non-transferable relationships). Экземпляр сущности не может быть перенесен из
одного экземпляра связи в другой.
Методология IDEF1
Так же, как и метод Баркера позволяет построить модель данных, эквивалентную реляционной модели в
третьей нормальной форме. На основе IDEF1 построена методология IDEF1X (в таких CASE-системах, как
ERWin, Design/IDEF).
Некоторые особенности IDEF1
Сущности могут быть независимыми (каждый экземпляр сущности может быть идентифицирован без
определения его отношений с другими сущностями) и зависимыми (однозначная идентификация экземпляра
сущности зависит от отношения к другой сущности).
Примеры:
студенческая группа – зависимая (от факультета)
доцент Иванов – зависимая (от кафедры)
президент Иванов – независимая
Для сущности задаются уникальное имя и номер (обозначаются, как <имя>/<номер>)
Связи могут быть дополнительно определены с помощью степени (мощности) – количество экземпляров
сущностей-потомков для каждого экземпляра сущности-родителя.
Виды мощностей связей IDEF1X:

0, 1 и более С-потомков (N)

не более 1 С-потомков (Р)

фиксированное число С-потомков (Z)
Изображение связей:
Существуют:
Идентифицирующая связь – позволяет однозначно определять сущность потомка по отношению к сущности
родителю.
Неидентифицирующая связь – не позволяет однозначно определять сущность потомка по отношению к
сущности родителю.
Аналоги этих видов связей в классической ER-модели: обязательная и необязательная.
Пример диаграммы IDEF1
Вопросы для самопроверки
1. Приведите примеры элементов ER-модели: сущностей, связей и атрибутов.
2. Каков порядок разработки ER-модели?
3. Какие характеристики связей между сущностями в ER-модели вы знаете?
4. Какие виды атрибутов сущностей, используемых в ER-модели вы знаете?
5. Что такое "супертип" данных, иногда используемый при построении ER-модели?
6. Зависит ли ER-модель от СУБД, которая используется (будет использоваться)? Почему?
9. Введение в UML
Объектно-ориентированный подход к разработке КИС
Сущность
С помощью объектно-ориентированного подхода можно разделить приложение на множество маленьких частей,
или объектов, относительно независимых друг от друга. Готовое приложение создается из этих объектов.
Следует отметить, что разработав объекты (и компоненты) ИС только один раз, они могут быть использованы
многократно.
Отличия от традиционных подходов
В соответствии с такими подходами основное внимание уделяется информации, с которой работает система.
Это подходы, ориентированные на данные (data-centric). Они важны при проектировании баз данных и систем
сбора информации, но при разработке бизнес-приложений возникают проблемы, связанные с трудностями
изменения деловых правил или поведения системы со временем.
В объектно-ориентированная (ОО) подходе внимание одинаково уделяется как информации, так и поведению.
Соответственно, теперь мы можем создавать гибкие системы, позволяющие изменять содержащуюся в них
информацию и/или их поведение.
Принципы
Преимущества гибкости могут быть реализованы только при правильном проектировании таких систем. Это
требует знания нескольких принципов объектно-ориентированного подхода: инкапсуляции, наследования и
полиморфизма.
Инкапсуляция
В ОО-системах данные комбинируются с конкретным поведением, или действиями, осуществляемыми над ними.
Все это объединяется в объект. Данный процесс называется инкапсуляцией.
Выгоды инкапсуляции
 Представление фрагментов системы в виде относительно независимых объектов.
 Возможность скрывать многочисленные детали объекта от внешнего мира.
 Ограничивает последствия изменений, вносимых в системы.
В результате – повышается гибкость ИС.
Пример
Допустим, например, что у нас имеется информация, касающаяся банковского счета, такая как номер счета,
баланс, имя и адрес его владельца, тип счета, начисляемые на него проценты и дата открытия. Со счетом также
связаны определенные действия: открыть, закрыть его, положить или снять некоторую сумму денег, а также
изменить тип, владельца или адрес. Вся эта информация и действия (поведение) совместно инкапсулируются в
объект account (счет). В результате все изменения банковской системы, связанные со счетами, могут быть
реализованы в одном только объекте account. Это напоминает покупку всех необходимых товаров только в
одном магазине.
Наследование
В ОО-системах наследование представляет собой механизм, позволяющий создавать новые объекты,
основываясь на уже существующих. Порождаемый (child) объект-потомок наследует свойства порождающего
или родительского (parent) объекта.
Преимущество - простота поддержки изменений объектов (изменение следует внести только в родительский
объект, а все потомки автоматически его наследуют).
Пример
В банковской системе наследование можно применять для работы с различными типами счетов. Наш
гипотетический банк обслуживает четыре типа счетов: до востребования (checking), сберегательный (savings),
кредитный (credit) и депозитный сертификат. Эти различные типы счетов имеют сходные черты, к которым
относятся номер счета, ставка процента и владелец. Итак, можно создать родительский объект account (счет) с
общими характеристиками всех счетов. Объекты-потомки будут иметь наследуемые и свои собственные
уникальные характеристики. Например, кредитный счет будет содержать лимит кредита и размер минимального
взноса. Депозитный сертификат содержит срок платежа. Изменения в родительском объекте повлияют на всех
потомков, но эти потомки могут адаптироваться и самостоятельно, не влияя друг на друга и на их предка.
Полиморфизм
Полиморфизм означает наличие множества форм или реализаций конкретной функциональности. В ООсистемах это означает, что конкретные функциональные возможности могут иметь множество реализаций.
Пример
Допустим, что мы разрабатываем систему рисования графиков. Когда пользователь хочет что-то нарисовать будь то линия или прямоугольник - система должна выполнить команду Draw (нарисовать). Наша система
включает множество типов различных форм, каждая из которых содержит поведение, позволяющее ей
нарисовать себя. Итак, когда пользователь хочет нарисовать круг, запускается команда draw() объекта "Круг". С
помощью полиморфизма система определяет, какую фигуру она должна нарисовать. При этом каждая форма
(круг, линия, прямоугольник и т.д.) должна тогда содержать собственную функцию drawMe() для ее рисования.
Что такое визуальное моделирование?
Визуальным моделированием (ВМ) называется процесс графического представления модели с помощью
некоторого стандартного набора графических элементов.
Основная цель ВМ – обеспечить общение между пользователями, разработчиками, аналитиками,
тестировщиками, менеджерами и всеми остальными участниками проекта. Наличие стандарта для этого обязательно.
Это общение можно обеспечить и с помощью невизуальной (текстовой) информации, однако легче понять
сложную информацию, если она представлена нам визуально.
Визуальная модель системы позволяет:
 Показать ее работу на различных уровнях.
 Моделировать взаимодействие между пользователями и системой.
 Мы можем моделировать взаимодействие объектов внутри системы.
 Моделировать взаимодействие между различными системами.
Метод Буча, OMT и UML
Важный вопрос ВМ - какую графическую нотацию использовать. Из всех предлагаемых вариантов наибольшую
поддержку получили метод Буча, технология объектного моделирования OMT (Object Modeling Technology) и
унифицированный язык моделирования UML (Unified Modeling Language).
Метод Буча назван по имени изобретателя, Гради Буча (Grady Booch) из Rational Software.
OMT была разработана Джеймсом Рамбо (Dr. James Rumbaugh). Использует более простую графику
моделирования систем по сравнению с методом Буча.
UML является результатом совместных усилий Гради Буча, Джеймса Рамбо, Ивара Якобсона (Ivar Jacobson),
Ребекки Вирс-Брок (Rebecca Wirfs-Brock), Питера Йордона (Peter Yourdon) и других. Символы UML сильно
напоминают нотации Буча и ОМТ, но содержат также элементы и из других нотаций.
Процесс консолидации методов, вошедших в состав UML, начался в 1993 году. В 1996 году Унифицированный
Метод был обновлен и преобразован в UML. В 1997 г. язык UML 1.1 объявлен промышленным стандартом.
Стандарт UML (текущая версия 1.4) был принят большинством производителей и такими комитетами по
стандартам, как ANSI и Object Management Group (OMG).
Диаграммы UML
Визуальные диаграммы UML
UML позволяет создавать визуальные диаграммы, описывающих различные аспекты системы (у каждой
диаграммы есть своя цель):
 Диаграммы Вариантов Использования
 Диаграммы Последовательности
 Кооперативные диаграммы
 Диаграммы Классов
 Диаграммы Состояний
 Диаграммы Компонентов
 Диаграммы Размещения
Все диаграммы вместе описывают систему с различных точек зрения.
Диаграммы Вариантов Использования
· Описывают функции, выполняемые системой (вариантами использования можно интерпретировать, как
функцию системы).
· Показывают взаимодействие между вариантами использования и действующими лицами.
· Отражают требования к системе с точки зрения пользователя.
· Показывают, какие действующие лица инициируют варианты использования.
· Показывают, когда действующее лицо получает информацию от варианта использования.
· Показывают взаимодействие с внешними системами.
Этот тип диаграмм описывает общую функциональность системы.
Пример
Пример диаграммы Вариантов Использования для банковского автомата (Automated Teller Machine, ATM)
показан на рис. 9.1.
Рис. 9.1. Диаграмма вариантов использования для ATM
Диаграммы Последовательности
Диаграммы Последовательности отражают поток событий, происходящих в рамках варианта использования.
Например, вариант использования "Снять деньги" предусматривает несколько возможных последовательностей,
такие как снятие денег, попытка снять деньги, не имея их достаточного количества на счету, попытка снять
деньги по неправильному идентификационному номеру и некоторые другие. Нормальный сценарий снятия 20
долларов со счета показан на рис. 9.2.
Рис. 9.2. Диаграмма последовательности для снятия клиентом 20 долларов со счета.
Эта диаграмма Последовательности показывает поток событий в рамках варианта использования "Снять
деньги". Все действующие лица (Клиент) показаны в верхней части диаграммы. Объекты, требуемые системе
для выполнения варианта использования "Снять деньги", также представлены в верхней части диаграммы.
Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между
объектами для выполнения требуемых функций.
Кооперативные диаграммы
Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы Последовательности. Однако
делают они это по-другому и с другими целями. Показанная на рисунке 2. диаграмма Последовательности
представлена на рис. 9.3 в виде Кооперативной диаграммы.
Рис. 9.3. Кооперативная диаграмма, описывающая процесс снятия Джо со своего счета $20
Диаграммы Классов
Диаграммы классов отражают взаимодействие между классами системы. Классы – это типы объектов.
Например, счет конкретного лица - это объект. Типом такого объекта можно считать счет вообще, то есть "Счет"
(account). Это и будет класс.
Классы содержат данные и поведение (действия), влияющее на эти данные. На диаграмме Классов класс
создается для каждого типа объектов из диаграмм Последовательности или Кооперативных диаграмм. С
помощью этих диаграмм можно показать детали системы.
Диаграмма Классов для варианта использования "Снять деньги" показана на рис. 9.4.
Рис. 9.4. Диаграмма Классов для варианта использования "Снять деньги"
На этой диаграмме Классов показаны связи между классами, реализующими вариант использования "Снять
деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account
(счет), ATM Screen (экран АТМ) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме Классов
выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй -- его
атрибуты. Атрибут -- это некоторая информация, характеризующая класс. Например, у класса Account (счет)
имеется три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В
последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У
класса Account имеется четыре операции: Open (открыть), Withdraw Funds (снять деньги), Deduct Funds (вычесть
сумму денег из счета) и Verify Funds (проверить наличие денег).
Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом
ATM Screen (экран АТМ), потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс
Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку
они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и
операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса
закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса.
Account Number, PIN и Balance являются закрытыми атрибутами класса Account. Кроме того, операции Deduct
Funds и Verify Funds также закрыты для этого класса.
Разработчики используют диаграммы Классов для реального создания классов. Такие инструменты, как Rose,
могут генерировать основу кода классов, которую затем программисты заполняют деталями на выбранном ими
языке.
Диаграммы Состояний
Диаграммы Состояний дают возможность моделировать различные состояния, в которых может находиться
объект (поведение объекта). В отличие от диаграмм Классов, они моделируют динамику объектов.
На рис. 9.5 приводится пример диаграммы Состояний для банковского счета.
Видно, в каких состояниях может существовать счет. Можно также видеть процесс перехода счета из одного
состояния в другое. Например, если клиент требует закрыть открытый счет, он переходит в состояние "закрыт".
Требование клиента называется событием (event); события вызывают переход из одного состояния в другое.
Рис. 9.5. Диаграмма Состояний для класса Account.
На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). Начальное состояние
(всегда одно) выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан.
Конечное состояние (одно, несколько или ни одного) обозначается черной точкой в белом кружке, оно
соответствует состоянию объекта непосредственно перед его уничтожением. Когда объект находится в каком-то
конкретном состоянии, могут выполняться различные процессы (actions). В нашем примере при превышении
кредита клиенту посылается соответствующее сообщение.
Диаграммы Состояний не надо создавать для каждого класса, они применяются только в очень сложных
случаях.
Диаграммы Компонентов
На диаграмме Компонентов изображены компоненты ПО системы и связи между ними. Выделяют исполняемые
компоненты и библиотеки. При этом, как правило, принимается, что каждый класс модели преобразуется в
компонент исходного кода.
На рис. 9.6 изображена одна из диаграмм Компонентов. В данном случае команда разработчиков решила
строить систему с помощью языка С++. У каждого класса имеется свой собственный заголовочный файл и файл
с расширением .СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме.
Например, класс ATM screen преобразуется в компонент ATM Screen диаграммы. Он преобразуется также и во
второй компонент ATM Screen. Вместе эти два компонента представляют тело и заголовок класса ATM Screen.
Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует
файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также
называется спецификацией пакета, но соответствует заголовочному файлу класса языка С++ (файл с
расширением .Н). Компонент ATM.exe является спецификацией задачи и представляет поток обработки
информации (thread of processing). В данном случае поток обработки является исполняемой программой.
Рис. 9.6. Диаграмма Компонентов для клиента АТМ.
Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс Card
Reader зависит от класса ATM Screen. Это означает, что, для того, чтобы класс Card Reader мог быть
скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть
создан исполняемый файл ATMClient.exe. Подобная диаграмма может быть построена и для серверной части
приложения.
В общем случае у системы может быть несколько диаграмм компонентов, в зависимости от числа подсистем или
исполняемых файлов. Каждая подсистема является пакетом компонентов (в примере это пакеты для клиента и
сервера АТМ.
Диаграммы Компонентов применяются теми участниками проекта, кто отвечает за компиляцию системы. Из нее
видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы
системой. На такой диаграмме показано соответствие классов реализованным компонентам.
Диаграммы Размещения
Диаграммы Размещения показывают физическое расположение сети и местонахождение в ней различных
компонентов (рис.9.7).
Рис. 9.7. Диаграмма Размещения для системы АТМ
Клиентские программы АТМ будут работать в нескольких местах на различных сайтах. Через закрытые сети
будет осуществляться их сообщение с региональным сервером АТМ. На нем будет работать программное
обеспечение сервера АТМ. В свою очередь, посредством локальной сети региональный сервер будет
сообщаться с сервером банковской базы данных, работающим под управлением Oracle. Наконец, с
региональным сервером АТМ соединен принтер.
Наша система ATM, например, будет соответствовать трехуровневой архитектуре, когда на первом уровне
размещается база данных, на втором -- региональный сервер, а на третьем -- клиент.
Диаграмма Размещения используется менеджером проекта, пользователями, архитектором системы и
эксплуатационным персоналом, чтобы понять физическое размещение системы и расположение ее отдельных
подсистем. Менеджер проекта сможет объяснить пользователям, как будет выглядеть готовый продукт.
Эксплуатационный персонал сможет планировать работу по установке системы.
Визуальное моделирование и процесс разработки программного обеспечения
Разработка программного обеспечения
Разработка программного обеспечения - это сложный процесс, и его поэтапное аккуратное выполнение не
всегда возможно. В объектно-ориентированном процессе мы должны по многу раз небольшими шагами
проходить этапы анализа, проектирования, разработки, тестирования и установки системы.
Начальная фаза ВМ
Основные задачи:
 Исследование свойств системы на высоком уровне и документирование их.
 Определение действующих лиц и вариантов использования (без углубления в детали). Диаграммы полезно
показать пользователям, чтобы убедиться, что они являются достаточно полным представлением о
свойствах системы.
 Определение приоритетов в разработке (плана итераций).
 Подготовка оценок для высшего руководства (сколько времени потребует реализация, сколько это будет
стоить и насколько задача выполнима).
Начальная фаза завершается, когда данное исследование закончено и для работы над проектом выделены
необходимые ресурсы.
Начальная фаза проекта (в отличии от других фаз) в основном последовательна и неитеративна.
Уточнение
Основные задачи:
 Детализация вариантов использования. Из них составляется документ, называемый "Спецификация
требований к программному обеспечению" (Software Requirement Specification, SRS). SRS содержит
детальное описание всех требований к системе.
 Анализ рисков и кодирование прототипов (proofs-of-concept).
 Разработка тестов.
 Уточнение предварительных оценок.
Уточнение выполняется для каждого варианта использования в текущей итерации.
Фаза уточнения завершается, когда варианты использования детализированы и одобрены пользователями,
прототипы завершены настолько, чтобы уменьшить риски, и разработаны диаграммы Последовательности,
Кооперативные, Состояний и Классов.
Конструирование
Конструирование - это процесс разработки и тестирования программного обеспечения. Эта фаза выполняется
для каждого набора вариантов использования на каждой итерации.
Основные задачи:
 Определение всех оставшихся требований
 Разработка и тестирование программного обеспечения.
Так как ПО было полностью спроектировано в фазе уточнения, конструирование не предполагает большого
количество решений по проекту, что позволяет команде работать параллельно. Это означает, что различные
группы программистов могут одновременно работать над различными объектами создаваемого ПО, зная, что,
когда они закончат, система "сойдется".
На первом этапе конструирования надо разработать компоненты и диаграмму компонентов. После этого можно
начать генерацию (разработку) кода.
С помощью таких CASE-систем, как Rational Rose, можно автоматически создать определения классов,
атрибутов, областей действия (общих (public), закрытых (private) или защищенных (protected)), прототипы
функций и операторы наследования. Получив такой код, программисты могут сконцентрироваться на
специфических аспектах проекта, связанных с бизнес-логикой.
Конструирование завершено, когда программное обеспечение готово и протестировано.
Ввод в действие
Фаза ввода в действие наступает, когда готовый программный продукт передают пользователям.
Основные задачи
 Завершение работы над финальной версией продукта.
 Завершение финального приемочного тестирования.
 Завершение составления документации
 Подготовка к обучению пользователей.
Обновление (синхронизация) SRS, диаграмм Вариантов Использования, Классов, Компонентов и Размещения.
Вопросы для самопроверки
1. В чем отличие объектно-ориентированного подхода к проектированию КИС от традиционных подходов?
2. Перечислите основные принципы объектно-ориентированного подхода.
3. Что достигается объединением данных и операций над ними в объекты?
4. Что дает создание объекта на основе уже существующего?
5. Приведите пример нескольких реализаций одной функциональности.
6. Дайте определение понятия "визуальное моделирование".
7. Что позволяет и для кого предназначена визуальная модель системы?
8. Как расшифровывается аббревиатура "UML"?
9. Какие виды диаграмм предусматривает UML? Зачем UML предусматривает столько видов диаграмм?
10. Что описывает диаграмма Вариант использования?
11. Что описывает диаграмма Последовательности?
12. Что описывает Кооперативная диаграмма?
13. Что описывает диаграмма Классов?
14. Что описывает диаграмма Состояний?
15. Что описывает диаграмма Компонентов?
16. Что описывает диаграмма Размещения?
17. Перечислите основные фазы разработки ПО с использованием методов визуального моделирования.
18. Каковы основные задачи начальной фазы?
19. Каковы основные задачи фазы уточнения?
20. Каковы основные задачи фазы конструирования?
21. Каковы основные задачи фазы ввода в действие?
10. Определение потребности, оценка и выбор CASE-средств
Общая характеристика и классификация CASE-средств
Современный рынок CASE-средств насчитывает около 300 наименований.
Типичные компоненты CASE-средств
Интегрированные CASE-средства (поддерживающие полный жизненный цикл ПО) содержит следующие
компоненты:
 Репозиторий (основа CASE) обеспечивает хранение метаданных, версий проекта, синхронизацию данных
при групповой разработке, контроль на полноту и непротиворечивость.
 Графические средства анализа и проектирования обеспечивают создание и редактирование иерархически
связанных диаграмм, образующих модели ИС.
 Средства разработки приложения, в т.ч. языки UGL и генераторы кодов.
 Средства документирования.
 Средства тестирования.
 Средства управления проектом.
 Средства реинжиниринга.
Классификация по типам и категориям
Категории:
 локальные CASE для решения автономных задач (tools)
 частично интегрированные CASE для решения нескольких этапов ЖЦ
 полностью интегрированные средства CASE.
Типы (основные):
 Средства анализа (Upper CASE) – построение и анализ моделей предметной области: Power Designer
(Sybase), Design/IDEF (Meta Software), BPWin (Platinum)
 Средства анализа и проектирования (Middle CASE) – создание проектных спецификаций: компонентов,
интерфейсов, архитектуры, алгоритмов, структур данных: Designer/2000 (Oracle), Rational Rose (Rational
Software).
 Средства проектирования баз данных – моделирование данных и генерация схем баз данных (SQL): ERWin
(Platinum), Power Designer (Sybase), Database Designer (Oracle); а также во всех Middle CASE-средствах.
 Средства разработки приложений: PowerBuilder (Sybase), SQL Windows (Centura), Developer/2000 (Oracle),
Delphi and C++ Builder (Borland), Visual Studio (MS).
 Средства реинжиниринга – анализ программных кодов и схем БД и формирование на их основе различных
моделей и проектных спецификаций: практически во всех CASE типов 2-3.
Типы (вспомогательные)
 Средства планирования и управления проектами: MS Project.
 Средства документирования: SoDA (Rational Software).
Определение потребностей в CASE-средствах
Первый этап внедрения CASE
Это первый этап технологии внедрения CASE.
Анализ возможностей организации
Метод: анкетирование, интервью, неформальные оценки.
Руководство по сбору информации:
1. Общие вопросы:
1.1. Используемая модель ЖЦ.
1.2. Используемые методы, методологии, накопленный опыт.
1.3. Наличие внутренних стандартов (спецификации, проектирование, кодирование, тестирование).
1.4. Виды документации, выпускаемой в процессе ЖЦ ПО.
2. Проекты:
2.1. Средняя продолжительность проекта (чел.-мес.).
2.2. Среднее количество участников проекта.
3. Технологическая база:
3.1. Доступные вычислительные ресурсы, платформы для разработки.
3.2. Уровень доступности ресурсов, узкие места, время ожидания.
3.3. ПО, используемое в организации (готовые, собственные разработки).
3.4. Степень интеграции применяемых программных продуктов, механизмы интеграции.
3.5. Тип и уровень сетевых возможностей.
3.6. Используемые языки программирования.
3.7. Средний процент вновь разрабатываемых, повторно используемых и реально эксплуатируемых
приложений.
4. Персонал:
4.1. Реакция на внедрение новой технологии.
4.2. Наличие кадров, способных серьезно повлиять на отношение к новым средствам.
4.3. Наличие стремления "снизу" к совершенствованию средств и технологий.
4.4. Объем необходимого обучения.
4.5. Стабильность кадров.
5. Готовность:
5.1. Поддержка проекта со стороны высшего руководства.
5.2. Готовность к долгосрочному финансированию.
5.3. Готовность персонала к изменению технологии своей работы.
5.4. Готовность персонала на возможное кратковременное снижение продуктивности своей работы.
5.5. Готовность руководства к долговременному ожиданию отдачи от вложенных средств.
Определение организационных потребностей
Нереалистичные ожидания:
 Отсутствие воздействия на общую культуру и распределение ролей в организации.
 Понимание проектных спецификаций неподготовленными пользователями.
 Сопровождение персонала, связанного с ИТ.
 Уменьшение степени участия в проектах высшего руководства и менеджеров, экспертов предметных
областей, пользователей.
 Немедленное повышение продуктивной деятельности.
 Достижение абсолютной полноты и непротиворечивости спецификаций.
 Автоматическая генерация прикладных систем из проектных спецификаций.
 Немедленное снижение затрат, связанных с ИТ.
 Снижение затрат на обучение.
Потребности оформляются списком и назначаются приоритеты.
Полезно составлять матрицу: потребность  возможности CASE-средств.
Определение критериев успешного внедрения
Должны определяться по потребностям организации. Главное – повышение производительности разработки ПО.
Должно быть обязательно количественными (используются для сравнения), а не только качественными.
Основные критерии:
 точность стоимостных оценок.
 точность плановых оценок.
 соблюдение стандартов организации.
 степень повторного использования компонент.
Разработка стратегии внедрения CASE-средств
Имеются 2 основных стратегии:
Нисходящее проектирование
Полный анализ и декомпозиция всех процессов организации.
Преимущества:
 Максимально возможная автоматизация.
 Интегрированность средств автоматизации.
Недостатки:
 Значительная потребность в людских и финансовых ресурсах.
 Небыстрое практическое использование CASE-средств.
 Возможность серьезного изменения существующих в организации процессов.
Восходящее проектирование
Преимущества:
 минимальные затраты на небольшую автоматизацию.
 небольшие временные затраты.
 лучший контроль и регулирование процессов автоматизации.
Недостатки:
 потенциально слабая интегрированность составных частей ИС.
 отсутствие решения фундаментальных проблем.
Модель процесса оценки и выбора
Оценка CASE-средств
Оформляется стандартным образом по следующему плану:
1. Введение – общий обзор процесса оценки и перечень основных результатов.
2. Предпосылки – цель оценки и желаемые результаты, период времени оценки, определение ролей
специалистов, выполняющих оценку.
3. Подход к оценке – описание подхода к оценке, любые предположения и ограничения, принятые критерии
оценки.
4. Информация о CASE-средствах:
a) Наименование;
b) версия (год изготовления);
c) данные о поставщике, его контактный адрес и телефон;
d) конфигурация технических средств;
e) стоимостные данные;
f) описание CASE-средства (поддерживаемые процессы функционирования, поддерживаемые языки
программирования и системы баз данных);
5. Этапы оценки – выполняемые в процессе оценки конкретные действия.
6. Конкретные результаты – результаты, представленные в терминах критериев оценки.
7. Выводы и заключение.
8. Примечания.
Критерии оценки и выбора
Должны быть адаптированы к каждому конкретному случаю.
Пример набора критерия выбора CASE-средств
1. Поддержка полного жизненного цикла ИС.
2. Обеспечение целостности проекта и контроля за его состоянием.
3. Независимость от СУБД.
4. Поддержка одновременной работы группы разработчиков.
5. Открытая архитектура и возможности экспорта/импорта описаний.
6. Качество технической поддержки в России, стоимость приобретения.
7. Качество проектной документации.
8. Использование общепринятых нотаций и соглашений.
Вопросы для самопроверки
1. Назовите типичные компоненты CASE-средств.
2. Как CASE-средства классифицируются по типам и категориям?
3. Приведите примеры для основных типов CASE-средств.
4. Опишите модель процесса определения потребностей в CASE-средствах.
5. Какие методы используются при анализе возможностей организации с точки зрения определения
потребностей в CASE-средствах.
6. Каковы основные нереалистичные ожидания при определении потребностей в CASE-средствах?
7. Перечислите известные вам основные критерии успешного внедрения CASE-средств.
8. Каковы преимущества и недостатки стратегии нисходящего проектирования?
9. Каковы преимущества и недостатки стратегии восходящего проектирования?
10. Опишите модель процесса оценки и выбора CASE-средств
11. Перечислите основные разделы материала, который должен содержать оценку CASE-средств.
12. Перечислите основные критерии для оценки CASE-средств
11. Выполнение пилотного проекта и внедрение
Цели пилотного проекта
1. Подтвердить достоверность результатов оценки и выбора.
2. Определить подходящую область применения CASE-средства.
3. Собрать информацию для разработки плана практического внедрения.
4. Приобрести собственный опыт использования CASE.
Шаги пилотного проекта
Определение характеристик пилотного проекта
Пилотный проект должен обладать следующими характеристиками:
1. Типичность предметной области.
2. Масштабируемость.
3. Представительность – задачи должны хорошо пониматься всеми.
4. Критичность – ПП должен быть значимый, но не критичный.
5. Авторитетность – группа специалистов должна быть авторитетной.
6. Готовность проектной группы.
7. Непродолжительность.
Планирование пилотного проекта
План должен содержать следующую информацию:
1. Цели, задачи, критерии оценки.
2. Персонал.
3. Процедуры и соглашения: методология, технические соглашения (наименование, обозначение, стандарты),
организационные соглашения (учет использования ресурсов, контроль изменений, проверка качества,
экспертиза).
4. Обучение – виды, объем.
5. График и ресурсы.
Выполнение пилотного проекта
Основные шаги:
1. Приобретение, установка, интеграция.
2. Поддержка.
3. Периодические экспертизы.
Оценка пилотного проекта
Должны быть даны ответы на вопросы:
1. Целесообразно ли внедрять CASE-средства?
2. Какие конкретные особенности ПП привели к его успеху (неудаче)?
3. Какие проекты или подразделения могли бы получить выгоду от использования CASE-средств?
Принятие решения о внедрении
Схема принятия решения:
План перехода
Как для пилотного проекта, но более широко (см. подраздел "Планирование пилотного проекта"). Основные
дополнения:
1. Возможные риски и непредвиденные обстоятельства.
2. План конвертирования данных и снятия старых средств с эксплуатации.
3. Описание взаимосвязей между новыми и существующими средствами.
4. Процедуры администрирования БД.
Действия, выполняемые в процессе перехода
Основные действия следующие:
1. Поддержка текущего обучения.
2. Поддержка ролевых функций.
3. Управление обновлением версий.
4. Свободный доступ к информации.
5. Взаимодействие с поставщиками.
Оценка результатов перехода
Основные критерии:
1. Время разработки ПО.
2. Время работы конкретного специалиста.
3. Размер, сложность и качество ПО.
4. Удобство сопровождения.
Вопросы для самопроверки
1. Каковы цели пилотного проекта?
2. Каковы основные шаги пилотного проекта?
3. Какими главными характеристиками должен обладать пилотный проект, отличающими его обычного
проекта по разработке и внедрению ИС?
4. В чем заключается оценка пилотного проекта? Какие выводы должны быть сделаны после его
завершения?
5. Что, как правило, необходимо делать, если в результате выполнения пилотного проекта выявились
неадекватные ожидания пользователей?
6. Что, как правило, необходимо делать, если в результате выполнения пилотного не удовлетворены
потребности пользователей?
7. Что, как правило, необходимо делать, если в результате выполнения пилотного проекта выявилась его
неудачная организация?
8. Зачем нужен план перехода к практическому внедрению ИС?