Разработка автоматизированного рабочего места инспектора по начислению пенсии

7

Размещено на http://www.allbest.ru/

Разработка автоматизированного рабочего места инспектора по начислению пенсии

РЕФЕРАТ

Дипломный проект содержит 73 листа дипломного проекта, 36 рисунков, 10 таблиц, 7приложений, 46 источников литературы.

ИНФОРМАЦИОННАЯ СИСТЕМА, ПЕРЕДАЧА ДАННЫХ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ.

Дипломный проект выполнен на тему «Разработка автоматизированного рабочего места инспектора по начислению пенсии».

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

В проекте выполнен расчет пенсионного обеспечения для Государственного учреждении - Управление Пенсионного фонда РФ ..., осуществлен сбор требований к информационной системе.

THE ABSTRACT

The diploma paper consists of pages of the diploma paper, figures, tables, appendices, sources of used literature.

INFORMATION SYSTEM, DATA TRANSFER, INTERFASE, REQUIREMENTS, A MODEL OF LIVING CYCLE, SIMULATING, PLANING, REALIZATION, A MODEL OF STRUCTURE OF DATA, TESTING, PHYSICAL PRESENTING OF THE SYSTEM, LOGICAL PRESENTING OF THE SYSTEM.

The diploma paper goes out under the title working out « ».

The sources of data were the books, periodicals and electronic resources, which were used as the theoretical material of considered problems and as the practical aids for realization of the Project.

Planing to put the Mobile for was carried out in the project. The collection of requirements to information system was realized.

Содержание

Введение

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

1.2 Анализ предметной области

1.3 Сбор требований

1.4 Анализ и моделирование требований

1.5 Спецификация требований

1.6 Аттестация требований

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

2. Проектирование информационной системы

2.1 Архитектурное проектирование

2.2 Проектирование пользовательского интерфейса

2.3 Проектирование баз данных

2.4 Обоснование выбора платформы создания информационной системы

2.5 Проектирование модулей (функциональная модель)

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

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

3.3 Тестирование приложения

3.4 Методика развертывания приложения

3.5 Выводы к разделу

4. Управление информационными проектами

4.1 Выбор жизненного цикла разработки ПО

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

4.3 Создание структуры пооперационного перечня работ

4.4 Идентификация задач и действий

4.5 Оценка размера и повторного использования ПО

4.6 Оценка длительности и стоимости разработки ПО

4.7 Распределение ресурсов проекта

4.8 Оценка экономической эффективности

Заключение

THE CONCLUSION

Список литературы

ПРИЛОЖЕНИЕ А - Техническое задание (ТЗ)

Приложение Б - Логическая модель базы данных

Приложение В - Физическая модель базы данных

Приложение Г - Программный код системы

Приложение Д - Схема данных системы

Приложение Е - программный код SQL-запросов

Приложение Ж - диаграмма ганта

Введение

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

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

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

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

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

- анализ требований к системы и проектирование системы;

- разработка и реализация базы данных организации;

- разработка и реализация первого этапа клиент серверного приложения информационной системы;

- тестирование информационной системы;

- внедрение информационной системы в эксплуатацию;

- управление проектом разработки информационной системы

- оценка экономической эффективности информационной системы.

Созданная в ходе дипломного проектирования информационная система будет использоваться в качестве инструмента автоматизации рабочего места инспектора по начислению пенсии в Государственном учреждении - Управление Пенсионного фонда РФ ... (АРМ ИНП Чертковского района). автоматизация начисление пенсия

1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧНИЮ

1.1 Анализ существующих решений по автоматизации предметной области

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

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

Государственное учреждение - Управление Пенсионного фонда РФ ... уже долгие годы проводит свои расчеты в п. Чертково. В этой организации существует своя специфика построения организационной структуры (смотри рисунок 1.1)

Рисунок 1.1 - Организационная структура «АРМ ИНП Чертковского района»

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

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

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

Всего по области организовано порядка 30 автоматизированных рабочих мест (АРМ). Объем областной базы данных составляют показатели на 300 тыс. человек. Инспектор, который занимается приемом населения, работает с базой данных на компьютере. Это позволяет максимально эффективно и быстро изменять данные о получателе пенсии. В базе данных хранится весь спектр информации по выплате пенсии, выплате компенсаций лицам, пострадавшим от радиационных аварий и катастроф.

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

Все расчеты пенсии производятся из областного центра, на основании информации, передаваемой по каналам связи из районов и городов. Файлы информации по установленному графику при помощи модема передаются по телефонному каналу на удаленную ПЭВМ в Центр, а затем вводятся в выплатную базу данных, анализируются, обрабатываются в цикле месячного расчета с выдачей выплатной документации.

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

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

АРМ ИНП Чертковского района имеет мощный прикладной блок, обеспечивающий:

- автоматизированный расчет стажа;

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

- автоматизированное назначение пенсий с выдачей протокола и расчета;

- ввод сведений о работе;

- изменение способа выплаты;

- выдачу справок о получаемой пенсии;

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

Специфика работы органов АРМ ИНП Чертковского района состоит в том, что ввод пользователем любой информации должен санкционироваться пользователем более высокого уровня, т.к. она так или иначе касается денег. В связи с этим неотъемлемым элементом идеологии системы является работа в условиях локальной вычислительной сети (ЛВС), по которой информация переходит по иерархии от одного пользователя к другому, проверяется, санкционируется и попадает в конечном итоге в Центр на выплату. В целях повышения надежности и устойчивости функционирования система имеет в качестве резервной технологию обмена между рабочими станциями на внешних магнитных носителях.

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

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

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

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

1.2 Анализ предметной области

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

Для проведения анализа и реорганизации бизнес-процессов предназначено CASE - средство верхнего уровня All Fusion Process Modeler (BPwin), поддерживающие методологии IDEF0 (функциональная модель), DFD (Dataflow Diagram).

Для рассмотрения бизнес - процессов выполняющихся в отделе АСУ, необходимо использовать только две методологии IDEF0 и DFD. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы или бизнес-процессов в целом.

С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой. /30/

С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

Модель IDEF0. Для изучения бизнес-процессов блока «Начисление пенсии» рассмотрим диаграмму «Регистрация пенсионера», которая представлена в виде IDEF0 диаграмме. IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

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

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

- стрелки выхода (выходят из правой грани работы) - изображают данные или объекты, появляющиеся в результате выполнения работы;

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

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

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

Для общей видимости системы необходимо построить контекст «АРМ ИНП Чертковского района» (смотри рисунок 1.2). Входом для бизнес-процесса отдела АСУ являются клиент (пенсионер) на расчет пособия, выходом - рассчитанная пенсия и отчет. В качестве механизма реализации бизнес-процессов участвуют сотрудники отдела и оборудование, управляющие воздействия определяются существующими нормативными справочными источниками и должностными инструкциями.



Рисунок 1.2 - Деятельность программного комплекса «АРМ ИНП Чертковского района»

На первом уровне декомпозиции выделены три обобщенных бизнес-процесса (смотри рисунок 1.3):

- оформление пенсионера;

- расчет пенсии;

- формирование отчетной документации.

При начислении пенсии в IT-отдел поступает информация о пенсионере и проходит процедуру регистрации. После регистрации, исходя из данных, происходит расчет пенсии. Выполненный расчет сопровождается, рассчитанной пенсией и отчетом о выполнении (смотри рисунок 1.3).



Рисунок 1.3 - Декомпозиция блока «начисление пенсии»

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

Рисунок 1.4 - Декомпозиция блока «расчет пенсии»

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

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

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

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

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

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

Из этой диаграммы (смотри рисунок 1.5) видно, что является входящими данными для данной системы, а что выходящими данными. Также на данной диаграмме отображены внешние сущности:

- источник информации является пенсионер;

- приемщик информации является финансовое ГОС учреждение и

- начальник пенсионного фонда.



Рисунок 1.5 - Диаграмма DFD «Деятельность «Инспектора»

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

Рисунок 1.6 - Диаграмма декомпозиции первого уровня

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

1.3 Сбор требований

Цель разрабатываемой информационной системы (ИС): Повышение эффективности и автоматизация рабочего места инспектора по начислению пенсии.

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

Обсуждая с руководством работу сотрудников пенсионного фонда были выявлены такие проблемы:

- нет возможности отслеживать работу инспекторов с потенциальными клиентами (пенсионерами) и принимать решения на основе объективной информации;

- проблематично использование стандартной формы расчета пенсии;

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

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

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

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

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

1.4 Анализ и моделирование требований

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

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

На данном этапе проектирования АИС необходимо расписать анализ оптимальной организации работ (стандарт IDEF - TO BE). Но так как заказчиком данной АИС было решено не менять процесс организации работ, то данная модель примет вид точно такой же, как и IDEF AS IS.

Также на данном этапе необходимо описать оптимальную систему документооборота для организации (стандарт DFD - TO BE). Но и здесь руководство предприятия не захотело что-либо менять, так как их полностью устраивает существующая система документооборота.

1.5 Спецификация требований

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

В качестве технической базы системы используются ПЭВМ IBM PC/AT стандартной конфигурации, связанные в единую локальную вычислительную сеть (ЛВС), обеспечивающую информационный обмен между пользователями разного уровня и разнообразный сервис.

Условием эффективной работы системы является оснащение каждого инспектора микроучастка ПЭВМ и создание на этой базе автоматизированного рабочего места инспектора (АРМ) со своим фрагментом БД.

Таблица 1.1 - Категории описания требований

Категория	Описание
F	Функциональные требования, описывающие требуемую функциональность или прецеденты системы
C	Системные требования, такие как используемые платформы
P	Требования к представлению
R	Требования, определяющие риски

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

Таблица 1.2 - Функциональные требования

Требование	Тип	Описание
Расчет пенсии	F	Система должна осуществлять расчет согласно установленному шаблону
Выбор и добавление новых данных	F	При расчете пенсии система должна предоставлять для выбора имеющиеся данные
Сформировать отчёты	F	Необходимо сформировывать отчёты по определённым шаблонам и критериям
Выход из оболочки программы	F	Предоставление возможности закрытия сессии пользователя

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

Описания системных требований представлены в таблице 1.3

Таблица 1.3 - Функциональные требования

Требование	Тип	Описание
Среда разработки	C	СУБД Access 2003
Операционная система	C	Microsoft Windows XP 2002
Хранилище данных	C	MS Access 2003

Третья категория, которая используется в описании требований - это требования к представлению (Р). Требования к представлению описывают формирование требований к интерфейсу программного обеспечения для заказчика. Здесь рассматривается построение интерфейса таким образом, чтобы заказчик мог легко пользоваться программным обеспечением.

Описание требований к представлению рассмотрены в таблице 1.4.

Таблица 1.4 - Требования к представлению

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

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

Описание требований к рискам, рассмотрены в таблице 1.5.

Таблица 1.5 - Требования к рискам

Требование	Тип	Описание
Соответствие данных	R	Внесённые данные должны соответствовать исходной (реальной) информации
Результаты выполнения	R	Полное соответствие реальным данным
Сохранность данных	R	Система должна обеспечивать сохранность данных о начислениях и другой смежной информации
Не заполнение данных	R	Система должна препятствовать такому риску, как риск не заполнение необходимой информации

В системе реализованы три основные составляющие:

- единая база данных - хранилище всех данных системы;

- единый интерфейс - набор однотипных инструментов для работы в системе.

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

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

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

Важно отметить, что система допускает постепенное наращивание функциональности.

Атрибуты качества ПО:

система доступа пользователям с 8.00 до 20.00 часов.

1.6 Аттестация требований

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

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

Обзор требований. Требования системно анализируется рецензентами.

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

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

Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE - средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.

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

Рассматривая приведенные выше методы аттестации требований, остановимся подробно на методе прототипирование, который будем использовать для построения программы-прототипа.

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

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

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

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

Интерфейс программы-прототипа был разработан в Microsoft Access 2003, этот программный продукт позволяет боле точно создать интерфейс и в случае необходимости его изменить.

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

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

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

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

После анализа достоинств и недостатков объектно-ориентированного и структурного методов проектирования я решила использовать структурный метод проектирования (смотри таблицу 1.6).

Таблица 1.6 - Сравнение методов проектирования информационных систем

Объектно-ориентированный	Структурный
Достоинства
Автоматического создания значительной части программного кода на основе объектной модели.	Проверен временем и получил широкое распространение среди аналитиков и разработчиков.
Легкость и эффективность масштабирования и дальнейшего развития системы на основе готовых компонентов.	Большое количество программный продуктов (CASE-средств), поддерживающих данный подход.
Возможность дополнения методологии UML собственными элементами и видами диаграмм.	Наглядность и в большинстве случаев однозначное толкование диаграмм, а также понимание их неспециалистами.
Низкие расходы на эксплуатационное сопровождение.

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

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

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

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

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

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

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

Выводы к разделу

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

2. Проектирование информационной системы

2.1 Архитектурное проектирование

Информационные системы могут очень сильно различаться по своим функциям, архитектуре, реализации. Это зависит от той области, в которой они применяются. Однако можно выделить, по крайней мере, два свойства, которые являются общими для всех информационных систем. Во-первых, основными задачами любой информационной является сбор, хранение и обработка необходимой для пользователя информации. Именно поэтому основой любой информационной системы является среда хранения и доступа к данным. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, которые соответствуют области применения информационной системы. Во-вторых, любая информационная система ориентируются на конечного пользователя. Для разрабатываемой мной системы конечным пользователем является: инспектор. А так как пользователь разрабатываемой системы может быть на “Вы” с компьютером, то ему просто необходимо иметь простой, удобный, легко осваиваемый интерфейс. Но кроме этого интерфейс должен предоставлять конечным пользователям все функции, необходимые для его Работы. Но в тоже время не давать возможности конечному пользователю выполнять какие-либо ненужные для его работы действия.

Исходя из требований заказчика (Начальника АРМ ИНП Чертковского района), мне стало понятно, что разрабатываемая система должна быть однопользовательской, то есть предоставлять доступ одному пользователю. Он может работать с базой - изменять данные, добавлять, удалять.

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

Двухуровневая архитектура ? это традиционный подход к построению файл-серверной системы. Трехуровневая архитектура характерна для WEB - технологий и подключение к базе данных через сервер приложения.

В таблице 2.1 приведены достоинства и недостатки двух и трехуровневой архитектур.

Таблица 2.1 - Сравнительный анализ архитектур

Трех уровневая архитектура	Двух уровневая архитектура
Достоинства
Наивысшая степень актуальности информации	Привычность технологии для существующих в компании специалистов
100%-й контроль за финансовыми потоками	Независимость от качества телекоммуникаций
Резкое уменьшение финансовых потерь, связанных с недобросовестностью работников	Возможность физической блокировки доступа к данным
Низкие расходы на эксплуатационное сопровождение
Недостатки
Зависимость от качества телекоммуникаций	Отсутствие плюсов трех уровневой архитектуры

Именно поэтому было решено выбрать двухуровневую архитектуру методом организации информационной системы:

Структуру данной архитектуры можно увидеть на рисунке 2.2.

Рисунок 2.2 - Двух уровневая архитектура

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



Рисунок 2.3 - Архитектура "файл-сервер"

Интерфейс разрабатываемой системы и сервер БД разрабатывался в MS Access 2003.

2.2 Проектирование пользовательского интерфейса

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

Интерфейс программы состоит из следующих форм:

- стартовая форма системы «Программа» (смотри рисунок 2.4). Данная форма открывается при запуске программного продукта, тем самым начинается диалог программы с пользователями.

- форма авторизации пользователя «Главная» (смотри рисунок 2.5). На данном рисунке изображена авторизации пользователя - «Инспектор», но в системе производится авторизация каждого пользователя. Это необходимо, чтобы каждый работник мог работать только с необходимыми для него формами, а также вести документы, закрепленные за ним. При неправильном вводе логина или пароля система запрашивает на повторный ввод и выход из программы по завершению работы;

- стартовая форма для инспектора «Далее» (смотри рисунок 2.6). На данной форме работник выбирает необходимую работу, в данном случае, регистрацию пенсионера. Ему просто необходимо нажать на кнопку с необходимой работой, и откроется нужная форма;

- форма «Оформление пенсионера» (смотри рисунок 2.7). Данная форма предназначена для заведения, инспектором, личных данных пришедшего первый раз на учет в пенсионный фонд;

- форма «Расчет пенсии» (смотри рисунок 2.8). Данная форма предназначена для расчета пенсии определенному пенсионеру.

- форма «Сформировать отчет» (смотри рисунок 2.9). Данная форма предназначена для формирования отчета начальнику пенсионного фонда и передаче его в Финансовые учреждения;

7

Размещено на http://www.allbest.ru/

Рисунок 2.4 - Стартовая форма информационной системы

Рисунок 2.5 - Форма авторизации



Рисунок 2.6 - Стартовая форма для инспектора

Рисунок 2.7 - Форма «Оформление пенсионера»

Рисунок 2.8 - Форма «Расчет пенсии»



Рисунок 2.9 - Форма «Сформировать отчет»

2.3 Проектирование баз данных

Для проектирования базы данных был использован ERwin 4.0 от Computer Associates Int.

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

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

ERwin имеет два уровня представления модели - логический и физический. Развитые средства моделирования помогают лучше спроектировать базу данных. Предусмотрены возможности манипулирования атрибутами путем их буксировки, внесения изменений и нормализации "на лету". Средства редактирования непосредственно на диаграммах позволяют вносить в модель изменения, не открывая специальных диалоговых окон. Навигация по отношениям обеспечивает быстрое перемещение в больших моделях для перехода к родительским или дочерним объектам. /30/

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

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

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

- диаграмма сущность - связь (Entity Relationships Diagram (ERD));

- модель данных, основанная на ключах (Key Based model (KB));

- полная атрибутивная модель (Fully Attributed model (FA)).

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

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

Полная атрибутивная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи. /27/

Логическая модель данных представлена в приложении Б.

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

- диаграмма сущность - связь (Entity Relationships Diagram (ERD));

- модель данных, основанная на ключах (Key Based model (KB));

- полная атрибутивная модель (Fully Attributed model (FA)).

Диаграмма сущность - связь включает сущности и взаимосвязи, отражающие основные бизнес - правила предметной области. Такая диаграмма не слишком детализирована, в неё включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям. Диаграмма сущность - связь может включать связи «многие ко многим» и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.

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

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

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

2.4 Обоснование выбора платформы создания информационной системы

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

MS Access 2003;

Благодаря возможностям MS Access 2003 был создан пользовательский интерфейс.

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

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

Главная особенность Access заключается в объектах, которые можно создавать и комбинировать, создавая, таким образом, желаемую информационную систему.

Примеры таких объектов:

- таблица (table) - контейнер для данных. Состоит из записей (records), образующих таким образом набор записей (recordset). Все записи данной таблицы имеют одинаковый набор полей (fields).Каждое поле содержит данные определенного типа. Access обеспечивает различные типы (текстовый, числовой, денежный и т.д.) данных;

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

- форма (form) используется при вводе данных и их представление на экране компьютера;

- отчет (report) используется для представления данных из или нескольких таблиц для печати;

- страница (page) используется для ввода данных в базу и их редактирование с использованием средств Интернет (Internet) или Интранет (Intranet), т.е. без непосредственного использования для этой цели собственных средств редактирования, имеющихся в Access;

- макрос (macros) - последовательность команд Access, выполняемых автоматически в ответ на заданное событие;

- модуль (module) - группы деклараций и процедур программы Visual Basic, которые хранятся как единое целое.

Access также может легко импортировать данные и связаться с данными, представленные в форматах других компьютерных программ. Это является значительным плюсом.

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

2.5 Проектирование модулей (функциональная модель)

Для того, чтобы выбрать существующую или создать собственную информационную систему, а после создания внедрить ее, необходимо проанализировать работу предприятия в данный момент времени. Для того, чтобы проанализировать деятельность пенсионного фонда необходимо изучить его работу, взаимодействие с другими отделами, вышестоящими учреждениями, взаимодействие между персоналом учреждения. Следовательно, для анализа деятельности пенсионного фонда следует собрать знания о деятельности инспектора. При получении таких знаний строится функциональная модель существующей работы пенсионного фонда AS-IS («как есть»). Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ («как будет»). К таким недостатками можно отнести: