Разработка концепции информационной системы для поддержки принятия управленческих решений в области маркетинга региона
приемников информации, которые трудно расположить на листе бумаги
нормального формата, и кроме того, единственный главный процесс не
раскрывает структуры распределенной системы. Признаками сложности (в смысле
контекста) могут быть:
наличие большого количества внешних сущностей (десять и более);
распределенная природа системы;
многофункциональность системы с уже сложившейся или выявленной группировкой
функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом
контекстная диаграмма верхнего уровня содержит не единственный главный
процесс, а набор подсистем, соединенных потоками данных. Контекстные
диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных
функциональных подсистем проектируемой ИС как между собой, так и с внешними
входными и выходными потоками данных и внешними объектами (источниками и
приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения
функциональной структуры ИС на самой ранней стадии ее проектирования, что
особенно важно для сложных многофункциональных систем, в разработке которых
участвуют разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует
проверить на полноту исходных данных об объектах системы и изолированность
объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах,
выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою
очередь, может быть детализирован при помощи ДПД или миниспецификации. При
детализации должны выполняться следующие правила:
правило балансировки - означает, что при детализации подсистемы или
процесса детализирующая диаграмма в качестве внешних источников/приемников
данных может иметь только те компоненты (подсистемы, процессы, внешние
сущности, накопители данных), с которыми имеет информационную связь
детализируемая подсистема или процесс на родительской диаграмме;
правило нумерации - означает, что при детализации процессов должна
поддерживаться их иерархическая нумерация. Например, процессы,
детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и
т.д.
Миниспецификация (описание логики процесса) должна формулировать его
основные функции таким образом, чтобы в дальнейшем специалист, выполняющий
реализацию проекта, смог выполнить их или разработать соответствующую
программу.
Миниспецификация является конечной вершиной иерархии ДПД. Решение о
завершении детализации процесса и использовании миниспецификации
принимается аналитиком исходя из следующих критериев:
наличия у процесса относительно небольшого количества входных и выходных
потоков данных (2-3 потока);
возможности описания преобразования данных процессом в виде
последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной
информации в выходную;
возможности описания логики процесса при помощи миниспецификации небольшого
объема (не более 20-30 строк).
При построении иерархии ДПД переходить к детализации процессов
следует только после определения содержания всех потоков и накопителей
данных, которое описывается при помощи структур данных. Структуры данных
конструируются из элементов данных и могут содержать альтернативы, условные
вхождения и итерации. Условное вхождение означает, что данный компонент
может отсутствовать в структуре. Альтернатива означает, что в структуру
может входить один из перечисленных элементов. Итерация означает вхождение
любого числа элементов в указанном диапазоне. Для каждого элемента данных
может указываться его тип (непрерывные или дискретные данные). Для
непрерывных данных может указываться единица измерения (килограммы, рубли и
т.п.), диапазон значений, точность представления и форма физического
кодирования. Для дискретных данных может указываться таблица допустимых
значений.
После построения законченной модели системы ее необходимо
верифицировать (проверить на полноту и согласованность). В полной модели
все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно
описаны и детализированы. Выявленные недетализированные объекты следует
детализировать, вернувшись на предыдущие шаги разработки. В согласованной
модели для всех потоков данных и накопителей данных должно выполняться
правило сохранения информации: все поступающие куда-либо данные должны быть
считаны, а все считываемые данные должны быть записаны.
Методология IDEF. Метод IDEF1, разработанный Т.Рэмей (T.Ramey),
основан на подходе П.Чена и позволяет построить модель данных,
эквивалентную реляционной модели в третьей нормальной форме. В настоящее
время на основе совершенствования методологии IDEF1 создана ее новая версия
- методология IDEF1X. IDEF1X разработана с учетом таких требований, как
простота изучения и возможность автоматизации. IDEF1X-диаграммы
используются рядом распространенных CASE-средств (в частности, ERwin,
Design/IDEF).
Сущность в методологии IDEF1X является независимой от идентификаторов
или просто независимой, если каждый экземпляр сущности может быть
однозначно идентифицирован без определения его отношений с другими
сущностями. Сущность называется зависимой от идентификаторов или просто
зависимой, если однозначная идентификация экземпляра сущности зависит от
его отношения к другой сущности (рисунок 20).
[pic]
Сущности
Каждой сущности присваивается уникальное имя и номер, разделяемые
косой чертой "/" и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или
мощности (количества экземпляров сущности-потомка, которое может
существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть
выражены следующие мощности связей:
каждый экземпляр сущности-родителя может иметь ноль, один или более
связанных с ним экземпляров сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не менее одного связанного
с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя должен иметь не более одного связанного
с ним экземпляра сущности-потомка;
каждый экземпляр сущности-родителя связан с некоторым фиксированным числом
экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью
с сущностью-родителем, то связь называется идентифицирующей, в противном
случае - неидентифицирующей.
Идентифицирующая связь между сущностью-родителем и сущностью-потомком
изображается сплошной линией (рисунок 21). Сущность-потомок в
идентифицирующей связи является зависимой от идентификатора сущностью.
Сущность-родитель в идентифицирующей связи может быть как независимой, так
и зависимой от идентификатора сущностью (это определяется ее связями с
другими сущностями).
[pic]
Идентифицирующая связь
Пунктирная линия изображает неидентифицирующую связь (рисунок 22).
Сущность-потомок в неидентифицирующей связи будет независимой от
идентификатора, если она не является также сущностью-потомком в какой-либо
идентифицирующей связи.
[pic]
Неидентифицирующая связь
Атрибуты изображаются в виде списка имен внутри блока сущности.
Атрибуты, определяющие первичный ключ, размещаются наверху списка и
отделяются от других атрибутов горизонтальной чертой (рисунок 23).
[pic]
Атрибуты и первичные ключи
Сущности могут иметь также внешние ключи (Foreign Key), которые могут
использоваться в качестве части или целого первичного ключа или неключевого
атрибута. Внешний ключ изображается с помощью помещения внутрь блока
сущности имен атрибутов, после которых следуют буквы FK в скобках.
Методология DATARUN и инструментальное средство SE Companion.
Современные методологии и реализующие их технологии поставляются в
электронном виде вместе с CASE-средствами и включают библиотеки процессов,
шаблонов, методов, моделей и других компонент, предназначенных для
построения ПО того класса систем, на который ориентирована методология.
Электронные методологии включают также средства, которые должны
обеспечивать их адаптацию для конкретных пользователей и развитие
методологии по результатам выполнения конкретных проектов.
Процесс адаптации заключается в удалении ненужных процессов, действий
ЖЦ и других компонентов методологии, в изменении неподходящих или в
добавлении собственных процессов и действий, а также методов, моделей,
стандартов и руководств. Настройка методологии может осуществляться также
по следующим аспектам: этапы и операции ЖЦ, участники проекта, используемые
модели ЖЦ, поддерживаемые концепции и др.
Электронные методологии и технологии (и поддерживающие их CASE-
средства) составляют ядро комплекса согласованных инструментальных средств
среды разработки ИС.
Одной из наиболее распространенных в мире электронных методологий
является методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО
разбивается на стадии, которые связываются с результатами выполнения
основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме
ее результатов должен завершать план работ на следующую стадию.
Стадия формирования требований и планирования включает в себя
действия по определению начальных оценок объема и стоимости проекта. Должны
быть сформулированы требования и экономическое обоснование для разработки
ИС, функциональные модели (модели бизнес-процессов организации) и исходная
концептуальная модель данных, которые дают основу для оценки технической
реализуемости проекта. Основными результатами этой стадии должны быть
модели деятельности организации (исходные модели процессов и данных
организации), требования к системе, включая требования по сопряжению с
существующими ИС, исходный бизнес-план.
Стадия концептуального проектирования начинается с детального анализа
первичных данных и уточнения концептуальной модели данных, после чего
проектируется архитектура системы. Архитектура включает в себя разделение
концептуальной модели на обозримые подмодели. Оценивается возможность
использования существующих ИС и выбирается соответствующий метод их
преобразования. После построения проекта уточняется исходный бизнес-план.
Выходными компонентами этой стадии являются концептуальная модель данных,
модель архитектуры системы и уточненный бизнес-план.
На стадии спецификации приложений продолжается процесс создания и
детализации проекта. Концептуальная модель данных преобразуется в
реляционную модель данных. Определяется структура приложения, необходимые
интерфейсы приложения в виде экранов, отчетов и пакетных процессов вместе с
логикой их вызова. Модель данных уточняется бизнес-правилами и методами для
каждой таблицы. В конце этой стадии принимается окончательное решение о
способе реализации приложений. По результатам стадии должен быть построен
проект ИС, включающий модели архитектуры ИС, данных, функций, интерфейсов
(с внешними системами и с пользователями), требований к разрабатываемым
приложениям (модели данных, интерфейсов и функций), требований к доработкам
существующих ИС, требований к интеграции приложений, а также сформирован
окончательный план создания ИС.
На стадии разработки, интеграции и тестирования должна быть создана
тестовая база данных, частные и комплексные тесты. Проводится разработка,
прототипирование и тестирование баз данных и приложений в соответствии с
проектом. Отлаживаются интерфейсы с существующими системами. Описывается
конфигурация текущей версии ПО. На основе результатов тестирования
проводится оптимизация базы данных и приложений. Приложения интегрируются в
систему, проводится тестирование приложений в составе системы и испытания
системы. Основными результатами стадии являются готовые приложения,
проверенные в составе системы на комплексных тестах, текущее описание
конфигурации ПО, скорректированная по результатам испытаний версия системы
и эксплуатационная документация на систему.
Стадия внедрения включает в себя действия по установке и внедрению
баз данных и приложений. Основными результатами стадии должны быть готовая
к эксплуатации и перенесенная на программно-аппаратную платформу заказчика
версия системы, документация сопровождения и акт приемочных испытаний по
результатам опытной эксплуатации.
Стадии сопровождения и развития включают процессы и операции,
связанные с регистрацией, диагностикой и локализацией ошибок, внесением
изменений и тестированием, проведением доработок, тиражированием и
распространением новых версий ПО в места его эксплуатации, переносом
приложений на новую платформу и масштабированием системы. Стадия развития
фактически является повторной итерацией стадии разработки.
Методология DATARUN опирается на две модели или на два представления:
модель организации;
модель ИС.
Методология DATARUN базируется на системном подходе к описанию
деятельности организации. Построение моделей начинается с описания
процессов, из которых затем извлекаются первичные данные (стабильное
подмножество данных, которые организация должна использовать для своей
деятельности). Первичные данные описывают продукты или услуги организации,
выполняемые операции (транзакции) и потребляемые ресурсы. К первичным
относятся данные, которые описывают внешние и внутренние сущности, такие
как служащие, клиенты или агентства, а также данные, полученные в
результате принятия решений, как например, графики работ, цены на продукты.
Основной принцип DATARUN заключается в том, что первичные данные,
если они должным образом организованы в модель данных, становятся основой
для проектирования архитектуры ИС. Архитектура ИС будет более стабильной,
если она основана на первичных данных, тесно связанных с основными деловыми
операциями, определяющими природу бизнеса, а не на традиционной
функциональной модели.
Любая ИС (рисунок 24) представляет собой набор модулей, исполняемых
процессорами и взаимодействующих с базами данных. Базы данных и процессоры
могут располагаться централизованно или быть распределенными. События в
системе могут инициироваться внешними сущностями, такими как клиенты у
банкоматов или временные события (конец месяца или квартала). Все
транзакции осуществляются через объекты или модули интерфейса, которые
взаимодействуют с одной или более базами данных.
Модель ИС
Подход DATARUN преследует две цели:
определить стабильную структуру, на основе которой будет строиться ИС.
Такой структурой является модель данных, полученная из первичных данных,
представляющих фундаментальные процессы организации;
спроектировать ИС на основании модели данных.
Объекты, формируемые на основании модели данных, являются объектами
базы данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты
интерфейса, определенные в архитектуре компьютерной системы, обычно
размещаются на клиентской части. Модель данных, являющаяся основой для
спецификации совместно используемых объектов базы данных и различных
объектов интерфейса, обеспечивает сопровождаемость ИС. На рисунке 25
представлена последовательность шагов проектирования ИС.
На рисунке 26 определены модели, создаваемые в процессе разработки
ИС. Для их создания используется CASE-средство Silverrun. Silverrun
обеспечивает автоматизацию проведения проектных работ в соответствии с
методологией DATARUN. Предоставляемая этими средствами среда проектирования
дает возможность руководителю проекта контролировать проведение работ,
отслеживать выполнение работ, вовремя замечать отклонения от графика.
Каждый участник проекта, подключившись к этой среде, может выяснить
содержание и сроки выполнения порученной ему работы, детально изучить
технику ее выполнения в гипертексте по технологиям, и вызвать инструмент
(модуль Silverrun) для реального выполнения работы.
Информационная система создается последовательным построением ряда
моделей, начиная с модели бизнес-процессов и заканчивая моделью программы,
автоматизирующей эти процессы.
[pic]
Последовательность шагов проектирования системы
[pic]
Модели, создаваемые с помощью подхода DATARUN
BPM (Business Process Model) - модель бизнес-процессов.
PDS (Primary Data Structure) - структура первичных данных.
CDM (Conceptual Data Model) - концептуальная модель данных.
SPM (System Process Model) - модель процессов системы.
ISA (Information System Architecture) - архитектура информационной системы.
ADM (Application Data Model) - модель данных приложения.
IPM (Interface Presentation Model) - модель представления интерфейса.
ISM (Interface Specification Model) - модель спецификации интерфейса.
Создаваемая ИС должна основываться на функциях, выполняемых
организацией. Поэтому первая создаваемая модель - это модель бизнес-
процессов, построение которой осуществляется в модуле Silverrun BPM. Для
этой модели используется специальная нотация BPM. В процессе анализа и
спецификации бизнес-функций выявляются основные информационные объекты,
которые документируются как структуры данных, связанные с потоками и
хранилищами модели. Источниками для создания структур являются используемые
в организации документы, должностные инструкции, описания производственных
операций. Эти данные вводятся в том виде, как они существуют в деятельности
организации. Нормализация и удаление избыточности производится позже при
построении концептуальной модели данных в модуле Silverrun ERX. После
создания модели бизнес-процессов информация сохраняется в репозитории
проекта.
В процессе обследования работы организации выявляются и
документируются структуры первичных данных. Эти структуры заносятся в
репозиторий модуля BPM при описании циркулирующих в организации документов,
сообщений, данных. В модели бизнес-процессов первичные структуры данных
связаны с потоками и хранилищами информации.
На основе структур первичных данных в модуле Silverrun ERX создается
концептуальная модель данных (ER-модель). От структур первичных данных
концептуальная модель отличается удалением избыточности, стандартизацией
наименований понятий и нормализацией. Эти операции в модуле ERX выполняются
при помощи встроенной экспертной системы. Цель концептуальной модели данных
- описать используемую информацию без деталей возможной реализации в базе
данных, но в хорошо структурированном нормализованном виде.
На основе модели бизнес-процессов и концептуальной модели данных
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
|