История возникновения стандарта IDEF0. Особенности процесса и концепции методологии функционального моделирования SADT, ее структура и применение. Пример практической разработки модели информационной системы "Управления федерального казначейства".
Аннотация к работе
Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.Механическое следование требованиям стандарта IDEF0 приводит, как правило, к игнорированию интерфейсов бизнес-процессов или к неполноте их описания. Беда не в том, что большая часть логики бизнес-процессов оказывается упущенной (ее можно восстановить позже), а в том, что логика операций, которые должны принадлежать одному из бизнес-процессов, часто возлагается проектировщиком на другие бизнес-процессы. Тем самым еще больше разрушается структурная однородность и универсальность представления бизнес-процессов.
Введение
В конце 90-х годов, когда увеличилась конкуренция и рентабельность деятельности предприятий стала резко падать, руководители столкнулись с огромными сложностями, пытаясь оптимизировать затраты, сделать продукцию одновременно и прибыльной, и конкурентоспособной. Четко обозначилась необходимость иметь модель деятельности предприятия, отражающую все механизмы и принципы взаимосвязи различных подсистем в рамках одного бизнеса.
Понятие "моделирование бизнес-процессов" вошло в обиход большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Внедрение подобных систем всегда подразумевает проведение глубокого пред проектного исследования деятельности компании. Результатом такого исследования становится экспертное заключение, где отдельно даются рекомендации по устранению "узких мест" в управлении деятельностью организации. На основании экспертного заключения, непосредственно перед началом проекта, проводится так называемая реорганизация бизнес-процессов, часто достаточно серьезная и болезненная для компании.
Для моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К ним относятся, в частности, методологии семейства IDEF, с помощью которых можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом глубина исследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
В настоящий момент к семейству IDEF можно отнести следующие стандарты: · IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0 представляет изучаемую систему в виде набора взаимосвязанных функций ("функциональных блоков"). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
· IDEF1 - методология моделирования информационных потоков внутри системы. Позволяет отображать и анализировать их структуру и взаимосвязь;
· IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий "Сущность-взаимосвязь" (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;
· IDEF2 - методология динамического моделирования развития систем. Изза серьезных сложностей, связанных с анализом динамических систем, от этого стандарта сейчас практически отказались, и его развитие приостановилось на самом начальном этапе. Существующие алгоритмы и их компьютерные реализации позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets);
· IDEF3 - методология документирования процессов, происходящих в системе. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 напрямую связана с методологией IDEF0: каждая функция (функциональный блок) может быть представлена средствами IDEF3 в виде отдельного процесса;
· IDEF4 - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и принципы их взаимодействия, позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
· IDEF5 - методология онтологического исследования сложных систем. С помощью словаря терминов и правил позволяет описать онтологию системы. В итоге могут быть сформированы достоверные утверждения о состоянии системы в некоторый момент времени, на основе которых делаются выводы о дальнейшем развитии системы и производится ее оптимизация.
Цели: Расширить представления о функциональном моделировании SADT.
Задачи: На основе полученных знаний о Функциональном моделировании SADT разработать свою информационную систему.
1. Теоретическая часть: «Моделирование SADT»
1.1 История возникновения стандарта IDEF0
Методологию IDEF0 можно считать конечным этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique)
Стандарт IDEF0 был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing), предложенной департаментом Военно-Воздушных Сил США. Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы(IDEF-ICAMDEFINITION).
Во время реализации программы возникла необходимость разработать новые методы анализа процессов взаимодействия в промышленных системах. Кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований стало наличие эффективной методологии взаимодействия в рамках "аналитик-специалист". Новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта. Так и возникла методология функционального моделирования IDEF0.
C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера. Последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандартам и Технологиям США (NIST).
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях: · графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
· строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: · ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
· связность диаграмм (номера блоков);
· уникальность меток и наименований (отсутствие повторяющихся имен);
· синтаксические правила для графики (блоков и дуг);
· разделение входов и управлений (правило определения роли данных).
· отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Состав функциональной модели
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис.1.).
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Рис 1. Функциональный блок и интерфейсные дуги моделирование информационный система sadt
На рисунке 2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.
Иерархия диаграмм
Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также представляют полный набор внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
Рис.2 Структура SADT-модели. Декомпозиция диаграмм
На рисунках 3 - 5 представлены различные варианты выполнения функций и соединения дуг с блоками.
Рис.3 Одновременное выполнение
Рис. 4 Соответствие должно быть полным и непротиворечивым
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рисунок 5).
Рис. 5 Пример обратной связи
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рисунок 6).
Рис. 6 Пример механизма
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.
Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7 показано типичное дерево диаграмм.
Рис. 7 Иерархия диаграмм
Типы связей между функциями
Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания: Тип связи Относительная значимость
Случайная 0
Логическая 1
Временная 2
Процедурная 3
Коммуникационная 4
Последовательная 5
Функциональная 6
Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.
(0) Тип случайной связности: наименее желательный.
Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на рисунке 8.
Рис. 8 Случайная связность
(1) Тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.
(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 9.
Рис. 9 Процедурная связность
(4) Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок 10).
(5) Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости (рисунок 11).
(6) Тип функциональной связности. Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги, как показано на рисунке 12.
Рис.10 Коммуникационная связность
Рис. 11 Последовательная связность
В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рисунке 12, имеет следующий вид: C = g(B) = g(f(A))
Ниже в таблице представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.
Рис. 12 Функциональная связность
Значимость Тип связности Для функций Для данных
0 Случайная Случайная Случайная
1 Логическая Функции одного и того же множества или типа (например, "редактировать все входы") Данные одного и того же множества или типа
2 Временная Функции одного и того же периода времени (например, "операции инициализации") Данные, используемые в каком-либо временном интервале
3 Процедурная Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") Данные, используемые во время одной и той же фазы или итерации
4 Коммуникационнная Функции, использующие одни и те же данные Данные, на которые воздействует одна и та же деятельность
5 Последовательная Функции, выполняющие последовательные преобразования одних и тех же данных Данные, преобразуемые последовательными функциями
6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией
1.3 Процесс моделирования SADT
В значительной мере успех методологии SADT объясняется ее графическим языком, хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний.
С полной уверенность можно сказать, что SADT является методологией в полном смысле, потому что она объединяет итеративный процесс создания модели, нотации, управляющие конфигурацией модели, язык ссылок для диаграмм, язык функций моделей с графическим языком описания системы, а также рекомендации по реализации аналитических проектов. Нотации, управляющие конфигурацией, гарантируют, что новые диаграммы будут корректно встроены в иерархическую структуру модели. Язык ссылок в SADT, правила сокращений для ссылок, адресованных к отдельным частям диаграммы, облегчают оформление замечаний при рецензировании модели. Язык функций позволяет декларативно определять правила работы системы, что часто является особенно важным завершающим шагом в описании системы.
На рис.1 изображен процесс моделирования в SADT, описанный с помощью SADT-диаграммы. Диаграмма отражает тот факт, что процесс моделирования в SADT является итеративной последовательностью шагов, приводящих к точному описанию системы. Высокая эффективность этого процесса обусловлена его организацией, в основе которой лежит разделение функций, выполняемых участниками создания.
SADT-проектов: эксперты являются источниками информации, авторы создают диаграммы и модели, библиотекарь координирует обмен письменной информацией, читатели рецензируют и утверждают модели, а Комитет технического контроля принимает и утверждает модель. В данной главе представлен общий обзор процесса моделирования. Более детально его отдельные шаги обсуждаются в главах 5 и 6, а также в частях II и III.
1. Получение знаний в процессе опроса
В процессе моделирования сведения об изучаемой системе получают с помощью испытанной методики сбора информации - опросов или интервью. Для получения наиболее полной информации SADT предлагает использовать различные ее источники (например, читать документы, опрашивать людей, наблюдать за работой системы). Независимо от конкретного источника информации методология SADT рекомендует руководствоваться определенной целью при его использовании. Это означает, что вы должны определить свои потребности в информации прежде, чем выбрать очередной источник. Во время опроса графический язык SADT используется как средство для заметок, которые служат основой для построения диаграмм.
Рис. 1. Процесс создания SADT-модели
2. Документирование полученных знаний
Создание модели (блок 2 на рис. 1) - это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной проблемной области, представляя их в виде одной или нескольких SADT-диаграмм. Процесс создания модели осуществляется с помощью специального метода детализации ограниченного субъекта. Коротко говоря, в SADT автор вначале анализирует объекты, входящие в систему, а затем использует полученные знания для анализа функций системы. На основе этого анализа создается диаграмма, в которой объединяются сходные объекты и функции. Этот конкретный путь проведения анализа системы и документирования его результатов является уникальной особенностью методологии SADT.
3. Корректность модели проверяется в процессе итеративного рецензирования.
Моделирование в SADT - инженерная дисциплина. Это означает, что модели создаются исходя из действительной ситуации и что эти модели проходят через серию последовательных улучшений до тех пор, пока они в точности не будут представлять реальный мир. Одной из основных компонент методологии SADT является итеративное рецензирование, в процессе которого автор и эксперт многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Итеративное рецензирование называется циклом автор/читатель.
Цикл автор/читатель начинается в тот момент, когда автор принимает решение распространить информацию о какой-либо части своей работы с целью получения отзыва о ней. Материал для распространения оформляется в виде "папок" - небольших пакетов с результатами работы, которые критически обсуждаются другими специалистами в течение определенного времени. Сделанные письменные замечания также помещаются в папку в виде нумерованных комментариев. Папки с замечаниями являются, таким образом, обратной связью, которую авторы получают на свою работу. Читатели - это те, кто читает и критикует создаваемую модель (см. блок 4 на рис. 1), а затем помещает замечания в папки. Их работа возможна благодаря тому, что графический язык SADT-диаграмм позволяет создавать диаграммы и модели, которые можно легко и быстро читать. (Простота графического языка потому не случайна. Она позволяет получить представление о системе, на основе которого можно дать обоснованное заключение о достоверности модели.)
Обычно отдельная папка рецензируется одновременно несколькими читателями, и все их замечания поступают к определенному сроку к автору. Затем автор отвечает на каждое замечание и обобщает критику, содержащуюся в замечаниях. С помощью таких обсуждений можно достаточно быстро обмениваться идеями. Таким образом, методология SADT поддерживает как параллельный, так и асинхронный просмотр модели, что является наиболее эффективным способом распределения работы в коллективе. Это показывает, что моделирование в SADT является инженерной дисциплиной, потому что итеративная коллективная деятельность - признак инженерной деятельности. Это связано с тем, что модель в SADT очень редко создается одним автором. На практике над различными частями модели могут совместно работать множество авторов, потому что каждый функциональный блок модели представляет отдельный субъект, который может быть независимо проанализирован и декомпозирован. Таким образом, модель сама координирует работу коллектива авторов, в то время как процесс моделирования SADT координирует совместное рецензирование возникающих идей. Полное описание инженерного процесса приведено в части III.
4. Координация процесса рецензирования
Организация своевременной обратной связи имеет важнейшее значение для эффективного моделирования, потому что устаревшая информация потенциально способна свести на нет все усилия по разработке системы. Вот почему SADT выделяет специальную роль наблюдателя за процессом рецензирования. На рис. 1 показано, что эту роль выполняет библиотекарь, который является главным координатором процесса моделирования в SADT, обеспечивая своевременное и согласованное распространение рабочих материалов. Библиотекарь распространяет полученные от авторов папки, контролирует их движение, рассылает напоминания о своевременном возвращении авторам папок с замечаниями и о сроках ответов авторов на предложения читателей. Кроме того, библиотекарь печатает законченные модели после того, как они одобрены и приняты к использованию.
5. Модели используются после их одобрения
Вспомним, что SADT-модели создаются с конкретной целью, и эта цель записана на диаграмме А-0 модели. В каком-то смысле эта цель определяет, как будет использоваться модель. Таким образом, как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели. Например, модель экспериментального механического цеха создана для описания деятельности различных работников механического цеха, хотя результирующая модель всегда предназначалась как основа учебного руководства для нового персонала. Если эта модель точно описывает работу персонала в цехе, но не может служить для подготовки учебного руководства - она бесполезна. Точная модель не всегда полезна.
В процессе SADT-моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа, называемая Комитетом технического контроля (см. блок 5 на рис. 1), отвечает за контроль качества моделей, создаваемых авторами SADT-проекта. Комитет следит за выполняемой работой и ее соответствием конечным целям всего проекта. Члены Комитета обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для достижения его глобальных целей.
Таким образом Комитет технического контроля находится в наиболее выгодном положении при определении текущего направления развития проекта и выработке предложений по его корректировке. Комитет реализует это с помощью рецензий. Модели, которые достигли желаемого уровня детализации и точности с точки зрения технических требований, направляются членам Комитета технического контроля для обсуждения и утверждения. Комитет оценивает, насколько применима данная модель. Если модель признана Комитетом применимой, она публикуется. В противном случае авторам направляются замечания для необходимой доработки.
2. Практическая часть: разработка модели информационной системы «Управления федерального казначейства»
2.1 Описание предметной области «Управления федерального казначейства»
Казначейство молодая развивающаяся структура государства ей всего 15 лет. Однако с каждым годом в ней меняется законодательная база, постоянно увеличивается объем обработки расходный документов следовательно и возрастает объем информации. Для контроля за всеми входящими данными просто необходима автоматизация этой отрасли для более высокой производительности и снятия загруженности для работников.
Система Управления федерального казначейства представляет собой так называемый «коробочный» программный продукт, несложный в эксплуатации и доработке. Она очень легкая для понимания и обучения, каждый режим работы снабжен подробными подсказками. Сотрудникам отдела АСУ не потребуется тратить свое время на объяснение менеджерам и бухгалтерам основ программирования, система максимально адаптирована под конечного пользователя и оперирует исключительно экономическими и финансовыми терминами и понятиями.
Также система Управления федерального казначейства позволяет быстрый доступ к базе данных Государственно расчетно-кассовому центру уменьшая время обработки документов и ожидания клиентов на выплаты.
Система Управления федерального казначейства связана на прямую с системой Государственного управления казначейства и с Контрольно-ревизионным управлением которые в свою очередь ведут контроль за использованием средств и всех денежных поступлений от Государственно расчетно-кассового центра.
2.2 Разработка модели информационной системы «Управления федерального казначейства»
Для разработки информационной системы Управления федерального казначейства был проведен аналитический опрос с работником управления казначейства для выявления основных направлений работы.
Казначейство выполняет 2 основные функции: 1. Открытие щитов по учету средств ФБ, бюджетов субъектов РФ, местных бюджетов в подразделение ЦБ РФ. И имеет свою базу данных расходов которой вся информация закодирована. Она отвечает за финансирование социальных программ финансирование получателей бюджетных средств. За котором идет непосредственный контроль, например: контроль за целевого использования средств, оперативная отчетность, бюджетная отчетность, контроль за исполнением расходных обязательств и т.п.
2. Распределение поступлений от федеральных налогов между бюджетами бюджетной системы. Дублирует налоговую службу и имеет свою базу данных непосредственно связанной с базой данных финансовой налоговой службой в которой также вся информация закодирована.
Вся отчетность о контроле ведется Контрольным ревизионным управлением и выступая в роли системы безопасности оно обеспечивает стабильность и надежность без потери каких либо данных.
Подключаемые базы данных доходов и расходов служат для оперативной отчетности перед налоговой службой и КРУ т.к все платежи и налоги осуществляются через федеральный бюджет.
2.3 Построение модели ИС «Казначейство», декомпозиция диаграмм
Иерархия диаграмм в ИС «Казначейство»
Механизмы информационной системы «Казначейство»
Декомпозиция диаграмм информационной системы «Казначейство»
DFD диаграмма ИС «Казначейство»
База данных «Расходов» информационной системы «казначейство».
База данных «Доходов» информационной системы «казначейство».
Вывод
Механическое следование требованиям стандарта IDEF0 приводит, как правило, к игнорированию интерфейсов бизнес-процессов или к неполноте их описания. Беда не в том, что большая часть логики бизнес-процессов оказывается упущенной (ее можно восстановить позже), а в том, что логика операций, которые должны принадлежать одному из бизнес-процессов, часто возлагается проектировщиком на другие бизнес-процессы.
Тем самым еще больше разрушается структурная однородность и универсальность представления бизнес-процессов. Следствием же является усложнение сопровождения модели на ее жизненном цикле и плохая масштабируемость модели (уникальность, неприспособленность к тиражированию и т.п.).
Следование предложенному в статье способу унификации описания бизнес-процессов позволяет избежать подобных неприятностей.
Насколько предложенный подход к унификации описания бизнес-процессов будет полезен конкретному проектировщику, сильно зависит от его личных пристрастий, опыта реализованных проектов и иных обстоятельств. Большое значение имеет и область применения разрабатываемой модели. Так, для описания документооборота возможно, целесообразнее использовать Swim Lane - диаграммы, строящиеся в Bpwin на основе IFEF3-диаграмм, или сразу начинать проектирование с DFD-диаграмм.
Предложенные «рецепты» являются выжимками приобретенного автором опыта при разработке процессных моделей нескольких организаций, для которого широта IDEF0 стандарта стала источником проектного «шума». Сущность приведенных рекомендаций выражается в направленном сужении стандартов организационного проектирования с целью «погружения» проектировщика в мир строгих абстракций, предлагаемых системной идеологией и общей теорией управления.
Данные рекомендации окажутся полезными директорам информационных служб при постановке задач системным аналитикам и определении требований к стандартам разработки информационных систем.
Список литературы
1. С. Рубцов, Какой CASE-инструмент нанесет наименьший вред организации? // Директор информационной службы, 2002, № 1 .
2. С. Рубцов, Взаимодействие открытых систем - старая концепция для новых идей. // Новые рынки, 2001, № 4.
3. С. Рубцов, Уточнение понятия "бизнес-процесс". Менеджмент в России и за рубежом, 2001, № 6.
4. «CASE - технологии. Современные методы и средства проектирования информационных систем.» учебник: Вендров А.М. - М.: Финансы и статистика,1998
5. R.J. Mayer, C.P. Menzel, M.K. Painter, P. S. DEWITTE, et al. Information Integration For Concurrent Engineering (IICE). IDEF3 Process Description Capture Method Report. - Wright-Patterson Air Force Base, Ohio: Air Force Materiel Command, 1995.
6. National Institute of Standards and Technology. Integration Definition For Function Modeling (IDEF0). - Washington: Draft Federal Information, 1993.
7. Сеть Интернет. -
8. Сеть Интернет. - http://www.testpro.pisem.net/TEIS/cycle.htm