Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

В большинстве случаев используемые программные комплексы хранят производственную информацию и эта информация должна быть доступна некоторому количеству пользователей и, зачастую, пользователи работают с данными одновременно. Эти идеи послужили основой концепции, согласно которой данные должны быть организованны в базы данных, для управления которыми, широко используются системы управления базами данных (СУБД).

Проектирование экономических информационных систем (ЭИС) - логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов.

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, в 1995г. компания StandishGroup проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы:

Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

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

На этом фоне, выгодно отличается структурный подход к проектированию ПО. Вот почему целью моей курсовой работы является раскрытие современных методов и средств проектирования, в частности, в структурном подходе к проектированию ИС.

В ходе выполнения работы были решены следующие задачи:

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

1. Структурные методы анализа и проектирования экономической информационной системы

При создании ЭИС требуется точно определить, какую именно систему нужно разрабатывать, чтобы ее внедрение способствовало повышению эффективности деятельности предприятия. Для этого необходимо разработать концепцию ЭИС, в которой дается целостное системное описание функционирования объекта автоматизации в рамках разработанной ЭИС. Концепция представляется с использованием техники диаграмм и таблиц, в виде схем, моделей, которые наглядно демонстрируют структуру и процессы в предметной области. Можно сказать, что разработка концепции ЭИС соответствует этапу эскизного проектирования системы. Таким образом, под концептуализацией разработки ЭИС понимается описание общих принципов ее проектирования, функционирования и эксплуатации.

Известно, что представление данных и знаний в информационно-вычислительной системе основано на концептуализации предметной области. Этап концептуализации - связан с обследованием будущего объекта.

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

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

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее.

1.1. Модель SADT

Метод SADT (IDEF0) (Structured Analysis and Design Technique) считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не инициировало соответствующие работы), на ее основе можно только внести предложения об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.

В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом:

1. Верхний уровень модели должен отражать только контекст системы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.

2. На втором уровне модели должны быть отражены основные виды деятельности (тематически сгруппированные бизнес-процессы) предприятия и их взаимосвязи. В случае большого их количества некоторые из них можно вынести на третий уровень модели. Но в любом случае под виды деятельности необходимо отводить не более двух уровней модели.

3. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций — совокупностей операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.

4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют когда и каким образом функции выполняются и управляются.
Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков — ограничение мощности краткосрочной памяти человека), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управлений (правило определения роли данных).
Отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель.

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

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

Функциональна модель IDEF0 (рисунок 1.5) — методология и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временна́я последовательность (WorkFlow).Так же отображаются все сигналы управления, которые на ПДП не отображались. Данная модель является одной из самых прогресивных моделей и используется при организации бизнес проектов и проектов основанных на моделировании всех процессов как административных, так и организационных.

Рисунок 1 – Принцип построения функциональной модели

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:-Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. -По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении.

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

• Верхняя сторона имеет значение “Управление” (Control);

• Левая сторона имеет значение “Вход” (Input);

• Правая сторона имеет значение “Выход” (Output);

• Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).

В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся (рисунок 2).

Рисунок 2 – Пример функциональной модели

Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.)

1.2 Модель DFD

При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища).

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

Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по подписки"). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.

Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, «номенклатура». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

Кроме основных элементов диаграммы, в состав входят словари данных и миниспецификации.

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

Все работы модели номеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д.. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию – нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы – номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.).

Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели для описания документооборота и обработки информации. Представляемая моделируемая система является сетью связанных работ. Основные компоненты DFD (как было сказано выше) – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).

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

Требуемые информационные потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую и описывается в виде функциональных диаграмм. Важность этих диаграмм очевидна. Они отражают и наглядно показывают логику работы скрытых связей, как цельной структуры. Потоки на диаграммах, как правило, изображаются именованными стрелками, ориентация которых указывает направление движения информации и их иерархическую значимость для всех заинтересованных лиц.

Иногда информационный поток может двигаться в одном направлении, обрабатываться и возвращаться назад к своему источнику. Такая ситуация может моделироваться либо двумя различными потоками, либо одним – двунаправленным.

1.3 Модель ERD

ERD состоит из трех основных блоков: сущностей, атрибутов и связей. Если рассматривать диаграмму как некий графический язык, то можно заметить, что объекты являются существительными, атрибуты – прилагательными, а зависимости – глаголами этого языка. Построение модели данных в ERwin заключается в, как бы, нахождении правильного набора существительных, глаголов и прилагательных и в правильном их сочетание.

Основная задача ERD – оценить, какие требования к бизнес-информации будут достаточными для обеспечения нужд планирования разработки информационной системы. Эти модели не очень подробны (включены только основные сущности), атрибуты тоже слабо детализируются. Разрешены отношения многие ко многим, ключи, как правило, не включаются. Эта модель, в основном, предназначена для презентации и обсуждения.

ERD разделяются на предметные области, в которых более детально описываются различные бизнес-функции. Наличие предметных областей позволяет представлять большие модели в более компактной форме. В результате модель становится легко управляемой и редактируемой.

Существует несколько способов разработки ERD. Они варьируют от формальных сессий моделирования (описанных в предыдущей статье) до индивидуальных интервью с менеджерами, обладающими большой сферой ответственности.

В этой статье речь пойдет о методе моделирования данных, используемом ERwin, и о мощности и удобстве этого метода для описания информационных структур вашего бизнеса.

Диаграмма зависимостей сущностей (диаграмма “сущность-связь”)

Рисунок 3 – Пример диаграммы зависимостей сущностей

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

В реляционной базе данных в каждой ячейке может храниться только один объект. В базе данных существует также взаимосвязь между таблицами. Каждая взаимосвязь представлена в RDBMS (РСУБД) за счет совместного использования одной или нескольких колонок двумя таблицами.

Так же, как таблицы и колонки образуют физическую модель реляционной базы данных, Диаграмма зависимостей сущностей (и другие логические модели) включают в себя компоненты, которые позволяют смоделировать структуры данных для вашего бизнеса. Логическим эквивалентом таблицы является сущность, а логическим эквивалентом колонки является атрибут.

Рисунок 4 – ERD с атрибутами

В ERD сущность представлен рамкой с именем этой сущности. Названия сущностей могут быть только в единственном числе – потребитель (а не потребители), фильм (а не фильмы), страна (а не страны). Если вы всегда будете использовать существительные в единственном числе, то можете получить единый стандарт для всех названий, и тем самым, сделать диаграмму более читаемой.

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

Эти связи создаются за счет использования общих ключей, т. е. записи в одной таблице ссылаются на записи в другой таблице. В ERD взаимосвязи отображены в виде линии между сущностями, входящими в модель. Связь между двумя сущностями также включает то, что факты одной сущности ссылаются или ассоциированы с фактами другой сущности.

В диаграмме, показанной выше, для фильмотеки требуется механизм отслеживания информации о потребителях и прокатных копиях фильмов. Информация этих двух сущностей взаимосвязана, и эта связь может быть выражена так: Потребитель берет напрокат одну или более Прокатных копий фильма.

Сущности могут быть определены в виде какого-либо лица, места, предмета, события, о которых содержится соответствующая информация. Если говорить точнее, то сущность можно представлять как набор отдельных экземпляров (записей). Экземпляр – это конкретная реализация сущности. Каждый экземпляр должен быть отличен от остальных.

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

В примере показанном выше, каждый экземпляр сущности Потребитель содержит следующую информацию: Id потребителя, имя потребителя, адрес потребителя. В логической модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

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

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

2.1 Постановка задачи

В современных условиях важной областью стало информационное обеспечение, которое состоит в сборе и переработке информации, необходимой для принятия обоснованных управленческих решений. Передача информации на высший уровень управления и взаимный обмен информацией между всеми взаимными подразделениями организации осуществляются на базе современной электронно-вычислительной техники и других технических средствах связи.

В ФНС для повышения эффективности работы возникла необходимость внедрения информационной системы документооборота.

Проанализировав деятельность ФНС, можно выявить следующие недостатки:

низкая оперативность;
преобладание ручной обработки информации и в связи с этим ее большая трудоемкость;
неэффективный обмен информацией внутри отдела;
дублирование информации;
сложность поиска актуальной версии документа.

Разработка ИС направлена в первую очередь на:

снижение трудоемкости процесса;
сокращение времени на всех стадиях процесса;
улучшение качества обслуживания;
снижение вероятности ошибок.

2.2 Построение модели

Функциональная модель существующего процесса документооборота при работе с налогоплательщиками представлена на рисунках 5–6.

Цель моделирования: выявить неавтоматизированные процессы для автоматизации и проектирования информационной системы.

Точка зрения: руководство.

Точка зрения: специалист по налогам, налоговый инспектор.

Рисунок 5 – Контекстная диаграмма существующего документооборота при работе с налогоплательщиками

Входами для процесса исполнения бюджета являются:

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

Управляющими воздействиями являются:

законы;
тарифы;
инструкции;
постановления и приказы.

В качестве механизмов рассматриваются:

отдел анализа отчетности и урегулирования задолженности;
отдел по работе с налогоплательщиками;
отделы камеральных и выездных проверок;
руководство;
АРМ, ПО.

Выходами (результатами) для процесса администрирования страховых взносов являются:

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

На рисунке 6 представлена декомпозиция контекстной модели существующего документооборота при работе с налогоплательщиками

Рисунок 6 – Декомпозиция контекстной модели существующего документооборота при работе с налогоплательщиками

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

А1. Зарегистрировать налогоплательщиков.
А2. Производить учет платежей.
А3. Проводить камеральные проверки.
А4. Проводить выездные проверки.
А5. Производить взыскание задолженностей.

Построена функциональная модель предлагаемого процесса по методологии IDEF0 (рисунок 7).

Рисунок 7 – Декомпозиция первого уровня предлагаемого процесса

На диаграмме (рисунок 8) представлена декомпозиция функционального блока «Осуществить работу с налогоплательщиками».

Рисунок 8 – Диаграмма декомпозиции первого уровня «Осуществить работу с налогоплательщиками»

Проектирование баз данных начинается с создания информационной модели приложения. Получение информационной модели называют инфологическим проектированием. Информационной моделью (ИМ) называют представление на некотором языке множества типов объектов, называемых сущностями, и отношений (связей) между ними. В качестве языка представления ИМ наибольшее распространение получил диаграммный язык, предлагаемый в методике информационного (инфологического) проектирования приложений IDEF1X, получившей международное признание.

Для представления информационной модели данных используется CASE-средство ERWin. С его помощью при проектировании модели информационной системы реализации строительных материалов была создана логическая модель данных.Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне - сущности и атрибуты. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Логический уровень модели данных представлен на рисунке 9.

Рисунок 9 – Логический уровень модели данных

На созданной диаграмме родительскими сущностями являются: «Налогоплательщики» (юридические лица и физические лица), «Сотрудник ФНС». Дочерними (зависимыми) сущностями являются: «Справки», «Проверки» (выездная и камеральная), «Заявление», «Отчеты».

2.3 Результаты моделирования

По разработанной информационной модели предлагаемой ИС построена база данных экономической информационной системы. Процесс проектирования базы данных в данном случае сводится к кодированию представленных в информационной модели сущностей как таблиц базы данных, а атрибутов сущностей как полей этих таблиц.

Типы и длина полей в таблицах базы данных выбираются с учетом обеспечения хранения в этих таблицах требуемой информации, а также оптимального использования памяти ЭВМ и достижения оптимальной скорости доступа к данным.

Структура базы данных представлена в таблицах 1 - 10.

Таблица 1

Сотрудник ФНС

Название поля	Тип данных	Значение атрибута
ID сотрудника	integer	PK
Должность	text
Фамилия	text
Имя	text
Отчество	text
Адрес	text
Телефон	text
E-mail	text
Паспорт	text

Таблица 2

Налогоплательщики

Название поля	Тип данных	Значение атрибута
ID налогоплательщика	integer	PK
Адрес	text
Телефон/факс	text
E-mail	text
ИНН	text
Счет в банке	text

Таблица 3

Юридические лица

Название поля	Тип данных	Значение атрибута
ID налогоплательщика	integer	FK
Документы об образовании юридического лица	text

Таблица 4

Физические лица

Название поля	Тип данных	Значение атрибута
ID налогоплательщика	integer	FK
паспорт	text

Таблица 5

Заявление

Название поля	Тип данных	Значение атрибута
Регистрационный номер	integer	PK
ID налогоплательщика	integer	FK
ID сотрудника	integer	FK
Дата подачи	date
Текст	text

Таблица 6

Справки

Название поля	Тип данных	Значение атрибута
ID справки	integer	PK
ID налогоплательщика	integer	FK
ID сотрудника	integer	FK
Дата выдачи	date
Суть	text

Таблица 7

Проверки

Название поля	Тип данных	Значение атрибута
ID сотрудника	integer	FK
Код проверки	integer	PK
ID налогоплательщика	integer	FK
Дата	date

Таблица 8

Камеральная проверка

Название поля	Тип данных	Значение атрибута
Код проверки	integer	PK
ID налогоплательщика	integer	FK
ID сотрудника	integer	FK
Суть	text
Результат	text

Таблица 9

Выездная проверка

Название поля	Тип данных	Значение атрибута
Код проверки	integer	PK
ID налогоплательщика	integer	FK
ID сотрудника	integer	FK
Суть	text
Результат	text
Адрес	text
Справка	text

Таблица 10

Отчеты

Содержание

Название поля	Тип данных	Значение атрибута
ID сотрудника	integer	FK
Суть	text
Вид	text
Дата	date
text

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

Заключение

Результатом данной работы является смоделированная «Информационная система документооборота в федеральной налоговой службе».

Предлагаемая ИС документооборота в федеральной налоговой службе, позволит:

организовать бизнес-процессы по работе с налогоплательщиками, исключить многократный ввод одних и тех же данных в информационную систему и оптимизировать ежедневную работу сотрудников ФНС;
наладить эффективный учет всей информации, относящейся к работе с налогоплательщиков;
вести учет в соответствии с законодательством;
снизить уровень бумажного документооборота;
повысить эффективность предприятия в целом, через повышение эффективности работы с налогоплательщиками.

В результате анализа были выявлены недостатки, влияющие на успешное функционирование ФНС. Проведен анализ существующих методик решения комплекса экономических задач. Сформулированы задачи усовершенствования экономической сущности комплекса задач. Рассмотрено преимущество внедрения ЭИС перед бумажным документооборотом. Проанализирована предметная область и построена ее концептуальная модель в виде функциональной модели «Осуществлять работу с налогоплательщиками».

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

Список использованной литературы

Агальцов, В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник / В.П. Агальцов. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. - 272 c.
Бритов Г., Осипова Т. Моделирование бизнес-процессов. - М.:LAP, 2014. – 124 с.
Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2012. - 400 c.
Давыдова Е. М. Базы данных Учеб. пособие для вузов / Е. М. Давыдова, Н. А. Новгородова. - 3-е изд., перераб. и доп. - Томск : В-Спектр, 2012. - 128 с.
Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 2012. - 360 c.
Илюшечкин В. Основы использования и проектирования баз данных. Учебник. - М.:Юрайт, 2014. - 214с.
Исаев Г. Проектирование информационных систем. Учебное пособие. - М.: Омега-Л, 2015. - 432с.
Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. - СПб.: Питер, 2013. - 240 c.
Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ-Петербург, 2012. - 464 c.
Коваленко В. Проектирование информационных систем. - М.: Форум, 2012. - 320с.
Кузин, А.В. Базы данных: Учебное пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. - М.: ИЦ Академия, 2012. - 320 c.
Малыхина М. Базы данных. Основы, проектирование, использование. - СПб.: БХВ-Петербург, 2012. - 528с.
Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник. – М.: Финансы и статистика, 2015. – 512 с.
Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2014. - 528 c.
Редько В.Н., Бассараб И.А. Базы данных и информационные системы. - М.: Знание, 2015. - 602 c.
Уткин В., Балдин К. Информационные системы в экономике. - М.: Academia, 2012. - 288с.
Хаббард Дж. Автоматизированное проектирование баз данных - М.: Мир, 2014. - 453 c.
Шаймарданов Р.Б. Моделирование и автоматизация проектирования структур баз данных - М.: Юнити, 2016. - 469 c.

Приложение

Алгоритм функционирования информационной системы