Разработка концепции информационной системы для поддержки принятия управленческих решений в области маркетинга региона

данных в выходные в соответствии с определенным алгоритмом. Физически

процесс может быть реализован различными способами: это может быть

подразделение организации (отдел), выполняющее обработку входных документов

и выпуск отчетов, программа, аппаратно реализованное логическое устройство

и т.д.

Процесс на диаграмме потоков данных изображается, как показано на

рисунке 17.

[pic]

Процесс

Номер процесса служит для его идентификации. В поле имени вводится

наименование процесса в виде предложения с активным недвусмысленным

глаголом в неопределенной форме (вычислить, рассчитать, проверить,

определить, создать, получить), за которым следуют существительные в

винительном падеже, например:

"Ввести сведения о клиентах";

"Выдать информацию о текущих расходах";

"Проверить кредитоспособность клиента".

Использование таких глаголов, как "обработать", "модернизировать" или

"отредактировать" означает, как правило, недостаточно глубокое понимание

данного процесса и требует дальнейшего анализа.

Информация в поле физической реализации показывает, какое

подразделение организации, программа или аппаратное устройство выполняет

данный процесс.

Накопители данных. Накопитель данных представляет собой абстрактное

устройство для хранения информации, которую можно в любой момент поместить

в накопитель и через некоторое время извлечь, причем способы помещения и

извлечения могут быть любыми. Накопитель данных может быть реализован

физически в виде микрофиши, ящика в картотеке, таблицы в оперативной

памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме

потоков данных изображается, как показано на рисунке 18.

[pic]

Накопитель данных

Накопитель данных идентифицируется буквой "D" и произвольным числом.

Имя накопителя выбирается из соображения наибольшей информативности для

проектировщика.

Накопитель данных в общем случае является прообразом будущей базы

данных и описание хранящихся в нем данных должно быть увязано с

информационной моделью.

Поток данных определяет информацию, передаваемую через некоторое

соединение от источника к приемнику. Реальный поток данных может быть

информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми

по почте письмами, магнитными лентами или дискетами, переносимыми с одного

компьютера на другой и т.д.

Поток данных на диаграмме изображается линией, оканчивающейся

стрелкой, которая показывает направление потока (рисунок 19). Каждый поток

данных имеет имя, отражающее его содержание.

[pic]

Поток данных

Построение иерархии диаграмм потоков данных. Первым шагом при

построении иерархии ДПД является построение контекстных диаграмм. Обычно

при проектировании относительно простых ИС строится единственная

контекстная диаграмма со звездообразной топологией, в центре которой

находится так называемый главный процесс, соединенный с приемниками и

источниками информации, посредством которых с системой взаимодействуют

пользователи и другие внешние системы.

Если же для сложной системы ограничиться единственной контекстной

диаграммой, то она будет содержать слишком большое количество источников и

приемников информации, которые трудно расположить на листе бумаги

нормального формата, и кроме того, единственный главный процесс не

раскрывает структуры распределенной системы. Признаками сложности (в смысле

контекста) могут быть:

наличие большого количества внешних сущностей (десять и более);

распределенная природа системы;

многофункциональность системы с уже сложившейся или выявленной группировкой

функций в отдельные подсистемы.

Для сложных ИС строится иерархия контекстных диаграмм. При этом

контекстная диаграмма верхнего уровня содержит не единственный главный

процесс, а набор подсистем, соединенных потоками данных. Контекстные

диаграммы следующего уровня детализируют контекст и структуру подсистем.

Иерархия контекстных диаграмм определяет взаимодействие основных

функциональных подсистем проектируемой ИС как между собой, так и с внешними

входными и выходными потоками данных и внешними объектами (источниками и

приемниками информации), с которыми взаимодействует ИС.

Разработка контекстных диаграмм решает проблему строгого определения

функциональной структуры ИС на самой ранней стадии ее проектирования, что

особенно важно для сложных многофункциональных систем, в разработке которых

участвуют разные организации и коллективы разработчиков.

После построения контекстных диаграмм полученную модель следует

проверить на полноту исходных данных об объектах системы и изолированность

объектов (отсутствие информационных связей с другими объектами).

Для каждой подсистемы, присутствующей на контекстных диаграммах,

выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою

очередь, может быть детализирован при помощи ДПД или миниспецификации. При

детализации должны выполняться следующие правила:

правило балансировки - означает, что при детализации подсистемы или

процесса детализирующая диаграмма в качестве внешних источников/приемников

данных может иметь только те компоненты (подсистемы, процессы, внешние

сущности, накопители данных), с которыми имеет информационную связь

детализируемая подсистема или процесс на родительской диаграмме;

правило нумерации - означает, что при детализации процессов должна

поддерживаться их иерархическая нумерация. Например, процессы,

детализирующие процесс с номером 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. После

создания модели бизнес-процессов информация сохраняется в репозитории

проекта.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9