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

Каскадная схема разработки ПО

Каскадный подход хорошо зарекомендовал себя при построении ИС, для

которых в самом начале разработки можно достаточно точно и полно

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

свободу реализовать их как можно лучше с технической точки зрения. В эту

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

другие подобные задачи. Однако, в процессе использования этого подхода

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

процесс создания ПО никогда полностью не укладывался в такую жесткую схему.

В процессе создания ПО постоянно возникала потребность в возврате к

предыдущим этапам и уточнении или пересмотре ранее принятых решений. В

результате реальный процесс создания ПО принимал следующий вид (рисунок 6):

Реальный процесс разработки ПО по каскадной схеме

Основным недостатком каскадного подхода является существенное

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

пользователями производится только в точках, планируемых после завершения

каждого этапа работ, требования к ИС "заморожены" в виде технического

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

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

завершена. В случае неточного изложения требований или их изменения в

течение длительного периода создания ПО, пользователи получают систему, не

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

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

утверждением.

Для преодоления перечисленных проблем была предложена спиральная

модель ЖЦ (рисунок 7 , делающая упор на начальные этапы ЖЦ: анализ и

проектирование. На этих этапах реализуемость технических решений

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

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

проекта, определяется его качество и планируются работы следующего витка

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

детали проекта и в результате выбирается обоснованный вариант, который

доводится до реализации.

Разработка итерациями отражает объективно существующий спиральный

цикл создания системы. Неполное завершение работ на каждом этапе позволяет

переходить на следующий этап, не дожидаясь полного завершения работы на

текущем. При итеративном способе разработки недостающую работу можно будет

выполнить на следующей итерации. Главная же задача - как можно быстрее

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

активизируя процесс уточнения и дополнения требований.

Основная проблема спирального цикла - определение момента перехода на

следующий этап. Для ее решения необходимо ввести временные ограничения на

каждый из этапов жизненного цикла. Переход осуществляется в соответствии с

планом, даже если не вся запланированная работа закончена. План

составляется на основе статистических данных, полученных в предыдущих

проектах, и личного опыта разработчиков.

[pic]

Спиральная модель ЖЦ

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

методологии и технологии. Методологии, технологии и инструментальные

средства проектирования (CASE-средства) составляют основу проекта любой ИС.

Методология реализуется через конкретные технологии и поддерживающие их

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

выполнение процессов ЖЦ.

Технология проектирования определяется как совокупность трех

составляющих:

пошаговой процедуры, определяющей последовательность технологических

операций проектирования;

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

технологических операций;

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

проектируемой системы.

Технологические инструкции, составляющие основное содержание

технологии, должны состоять из описания последовательности технологических

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

операция, и описаний самих операций.

Технология проектирования, разработки и сопровождения ИС должна

удовлетворять следующим общим требованям:

технология должна поддерживать полный ЖЦ ПО;

технология должна обеспечивать гарантированное достижение целей разработки

ИС с заданным качеством и в установленное время;

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

виде подсистем (т.е. возможность декомпозиции проекта на составные части,

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

последующей интеграцией составных частей). Опыт разработки крупных ИС

показывает, что для повышения эффективности работ необходимо разбить проект

на отдельные слабо связанные по данным и функциям подсистемы. Реализация

подсистем должна выполняться отдельными группами специалистов. При этом

необходимо обеспечить координацию ведения общего проекта и исключить

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

возникнуть в силу наличия общих данных и функций;

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

отдельных подсистем небольшими группами (3-7 человек). Это обусловлено

принципами управляемости коллектива и повышения производительности за счет

минимизации числа внешних связей;

технология должна обеспечивать минимальное время получения работоспособной

ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации

отдельных подсистем. Реализация ИС в целом в короткие сроки может

потребовать привлечения большого числа разработчиков, при этом эффект может

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

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

наличии полностью завершенного проекта, внедрение идет последовательно по

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

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

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

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

версиями проекта;

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

от средств реализации ИС (систем управления базами данных (СУБД),

операционных систем, языков и систем программирования).

Структурный подход к проектированию ИС. Сущность структурного

подхода. Сущность структурного подхода к разработке ИС заключается в ее

декомпозиции (разбиении) на автоматизируемые функции: система разбивается

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

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

до конкретных процедур. При этом автоматизируемая система сохраняет

целостное представление, в котором все составляющие компоненты

взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко

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

стыковке отдельных компонентов.

Все наиболее распространенные методологии структурного подхода

базируются на ряде общих принципов. В качестве двух базовых принципов

используются следующие:

принцип "разделяй и властвуй" - принцип решения сложных проблем путем их

разбиения на множество меньших независимых задач, легких для понимания и

решения;

принцип иерархического упорядочивания - принцип организации составных

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

деталей на каждом уровне.

Выделение двух базовых принципов не означает, что остальные принципы

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

привести к непредсказуемым последствиям (в том числе и к провалу всего

проекта). Основными из этих принципов являются следующие:

принцип абстрагирования - заключается в выделении существенных аспектов

системы и отвлечения от несущественных;

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

подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности

элементов;

принцип структурирования данных - заключается в том, что данные должны быть

структурированы и иерархически организованы.

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

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

Каждой группе средств соответствуют определенные виды моделей (диаграмм),

наиболее распространенными среди которых являются следующие:

SADT (Structured Analysis and Design Technique) модели и соответствующие

функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и

дополняются диаграммами, отражающими структуру программного обеспечения:

архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Перечисленные модели в совокупности дают полное описание ИС

независимо от того, является ли она существующей или вновь разрабатываемой.

Состав диаграмм в каждом конкретном случае зависит от необходимой полноты

описания системы.

Методология функционального моделирования SADT. Методология SADT

разработана Дугласом Россом и получила дальнейшее развитие в работе. На ее

основе разработана, в частности, известная методология IDEF0 (Icam

DEFinition), которая является основной частью программы ICAM (Интеграция

компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

Методология SADT представляет собой совокупность методов, правил и

процедур, предназначенных для построения функциональной модели объекта

какой-либо предметной области. Функциональная модель SADT отображает

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

между этими действиями. Основные элементы этой методологии основываются на

следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-

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

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

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

интерфейсных дуг, выражающих "ограничения", которые в свою очередь

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

строгость и точность. Выполнение правил SADT требует достаточной строгости

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

аналитика. Правила SADT включают:

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6

блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

отделение организации от функции, т.е. исключение влияния организационной

структуры на функциональную модель.

Методология SADT может использоваться для моделирования широкого

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

системы, которая удовлетворяет этим требованиям и реализует эти функции.

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

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

которых они осуществляются.

Состав функциональной модели. Результатом применения методологии SADT

является модель, которая состоит из диаграмм, фрагментов текстов и

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

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

Место соединения дуги с блоком определяет тип интерфейса. Управляющая

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

подвергается обработке, показана с левой стороны блока, а результаты выхода

показаны с правой стороны. Механизм (человек или автоматизированная

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

блок снизу (рисунок 8).

Одной из наиболее важных особенностей методологии SADT является

постепенное введение все больших уровней детализации по мере создания

диаграмм, отображающих модель.

Функциональный блок и интерфейсные дуги

На рисунке 9, где приведены четыре диаграммы и их взаимосвязи,

показана структура SADT-модели. Каждый компонент модели может быть

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

"внутреннее строение" блока на родительской диаграмме.

Иерархия диаграмм. Построение SADT-модели начинается с представления

всей системы в виде простейшей компоненты - одного блока и дуг,

изображающих интерфейсы с функциями вне системы. Поскольку единственный

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

является общим. Это верно и для интерфейсных дуг - они также представляют

полный набор внешних интерфейсов системы в целом.

[pic]

Структура SADT-модели. Декомпозиция диаграмм

Затем блок, который представляет систему в качестве единого модуля,

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

интерфейсными дугами. Эти блоки представляют основные подфункции исходной

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

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

дугами. Каждая из этих подфункций может быть декомпозирована подобным

образом для более детального представления.

Во всех случаях каждая подфункция может содержать только те элементы,

которые входят в исходную функцию. Кроме того, модель не может опустить

какие-либо элементы, т.е., как уже отмечалось, родительский блок и его

интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него

не может быть ничего удалено.

Модель SADT представляет собой серию диаграмм с сопроводительной

документацией, разбивающих сложный объект на составные части, которые

представлены в виде блоков. Детали каждого из основных блоков показаны в

виде блоков на других диаграммах. Каждая детальная диаграмма является

декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции

более общая диаграмма называется родительской для более детальной

диаграммы.

Дуги, входящие в блок и выходящие из него на диаграмме верхнего

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

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

одну и ту же часть системы.

На SADT-диаграммах не указаны явно ни последовательность, ни время.

Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по

времени) функции могут быть изображены с помощью дуг. Обратные связи могут

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

Как было отмечено, механизмы (дуги с нижней стороны) показывают

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

может быть человеком, компьютером или любым другим устройством, которое

помогает выполнять данную функцию (рисунок 10).

[pic]

Пример механизма

Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может

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

быть далее детализирована с помощью необходимого числа диаграмм. Таким

образом, формируется иерархия диаграмм.

Для того, чтобы указать положение любой диаграммы или блока в

иерархии, используются номера диаграмм. Например, А12 является диаграммой,

которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует

блок 2 на диаграмме А0, которая является самой верхней диаграммой модели.

На рисунке 11 показано типичное дерево диаграмм.

Иерархия диаграмм

Типы связей между функциями. Одним из важных моментов при

проектировании ИС с помощью методологии SADT является точная

согласованность типов связей между функциями. Различают по крайней мере

семь типов:

(0) Тип случайной связности: наименее желательный. Случайная связность

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

отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в

одной диаграмме имеют малую связь друг с другом.

(1) Тип логической связности. Логическое связывание происходит тогда, когда

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

общий класс или набор элементов, но необходимых функциональных отношений

между ними не обнаруживается.

(2) Тип временной связности. Связанные по времени элементы возникают

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

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

последовательно.

(3) Тип процедурной связности. Процедурно-связанные элементы появляются

сгруппированными вместе вследствие того, что они выполняются в течение

одной и той же части цикла или процесса.

(4) Тип коммуникационной связности. Диаграммы демонстрируют

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

используют одни и те же входные данные и/или производят одни и те же

выходные данные (рисунок 12).

(5) Тип последовательной связности. На диаграммах, имеющих последовательные

связи, выход одной функции служит входными данными для следующей функции.

Связь между элементами на диаграмме является более тесной, чем на

рассмотренных выше уровнях связок, поскольку моделируются причинно-

следственные зависимости (рисунок 13).

(6) Тип функциональной связности. Диаграмма отражает полную функциональную

связность, при наличии полной зависимости одной функции от другой.

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

элементов, относящихся к последовательному или более слабому типу

связности. Одним из способов определения функционально-связанных диаграмм

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

показано на рисунке 14.

Коммуникационная связность

Последовательная связность

В математических терминах необходимое условие для простейшего типа

функциональной связности, показанной на рисунке 14, имеет следующий вид:

C = g(B) = g(f(A)) (1)

Функциональная связность

Моделирование потоков данных (процессов). В основе данной методологии

(методологии Gane/Sarson) лежит построение модели анализируемой ИС -

проектируемой или реально существующей. В соответствии с методологией

модель системы определяется как иерархия диаграмм потоков данных (ДПД или

DFD), описывающих асинхронный процесс преобразования информации от ее ввода

в систему до выдачи пользователю. Диаграммы верхних уровней иерархии

(контекстные диаграммы) определяют основные процессы или подсистемы ИС с

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

уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию

диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции,

на котором процесс становятся элементарными и детализировать их далее

невозможно.

Источники информации (внешние сущности) порождают информационные

потоки (потоки данных), переносящие информацию к подсистемам или процессам.

Те в свою очередь преобразуют информацию и порождают новые потоки, которые

переносят информацию к другим процессам или подсистемам, накопителям данных

или внешним сущностям - потребителям информации. Таким образом, основными

компонентами диаграмм потоков данных являются:

внешние сущности;

системы/подсистемы;

процессы;

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

потоки данных.

Внешние сущности. Внешняя сущность представляет собой материальный

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

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

Определение некоторого объекта или системы в качестве внешней сущности

указывает на то, что она находится за пределами границ анализируемой ИС. В

процессе анализа некоторые внешние сущности могут быть перенесены внутрь

диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть

процессов ИС может быть вынесена за пределы диаграммы и представлена как

внешняя сущность. Внешняя сущность обозначается квадратом (рисунок 15),

расположенным как бы "над" диаграммой и бросающим на нее тень, для того,

чтобы можно было выделить этот символ среди других обозначений:

[pic]

Внешняя сущность

Системы и подсистемы. При построении модели сложной ИС она может быть

представлена в самом общем виде на так называемой контекстной диаграмме в

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

ряд подсистем.

Подсистема (или система) на контекстной диаграмме изображается

следующим образом (рисунок 16).

[pic]

Подсистема

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

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

определениями и дополнениями.

Процессы. Процесс представляет собой преобразование входных потоков

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