Рубрикатор 

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

 















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


РЕФЕРАТ


Дипломный проект содержит 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.diploma paper goes out under the title working out « ».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.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 - Организационная структура «АРМ ИНП Чертковского района»


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


.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 - Диаграмма декомпозиции первого уровня

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


.3 Сбор требований


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

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

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

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

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

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

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

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

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

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


.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Операционная системаCMicrosoft Windows XP 2002Хранилище данныхCMS Access 2003

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными, среди которых являются следующие:(Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; (Data Flow Diagrams) диаграммы потоков данных; (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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


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


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



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


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


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

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

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

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

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


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

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

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

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


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


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


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


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


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


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

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

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

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

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

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

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

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


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


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

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


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


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

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


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


Для проектирования базы данных был использован ERwin 4.0 от Computer Associates Int.- это средство конструирования баз данных, которое является мощным, но в то же время простым в использовании. Именно благодаря этому он завоевал широкое признание и популярность. Оно обеспечивает высочайшую продуктивность труда при разработке и сопровождении приложений с использованием баз данных. На протяжении всего процесса - от логического моделирования требований к информации и бизнес-правил, которые определяют базу данных, до оптимизации физической модели в соответствии с заданными характеристиками - ERwin позволяет наглядно отобразить структуру и основные элементы БД. - не только лучший инструмент для проектирования баз данных, но и средство для их быстрого создания. ERwin оптимизирует модель в соответствии с физическими характеристиками целевой базы данных. В отличие от других инструментальных средств, ERwin автоматически поддерживает согласованность логической и физической схем и осуществляет преобразование логических конструкций, таких как отношения многие-ко-многим, в их реализацию на физическом уровне. Облегчает проектирование баз данных. Для этого достаточно создать графическую E-R модель (объект-отношение), удовлетворяющую всем требованиям к данным и ввести бизнес-правила для создания логической модели, которая отображает все элементы, атрибуты, отношения и группировки. имеет два уровня представления модели - логический и физический. Развитые средства моделирования помогают лучше спроектировать базу данных. Предусмотрены возможности манипулирования атрибутами путем их буксировки, внесения изменений и нормализации "на лету". Средства редактирования непосредственно на диаграммах позволяют вносить в модель изменения, не открывая специальных диалоговых окон. Навигация по отношениям обеспечивает быстрое перемещение в больших моделях для перехода к родительским или дочерним объектам. /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 используется для презентаций и обсуждения структуры данных с экспертами предметной области.

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

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

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


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


Для автоматизации рабочего места инспектора по начислению пенсии была выбрана такой программный продукт как: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, которые хранятся как единое целое.также может легко импортировать данные и связаться с данными, представленные в форматах других компьютерных программ. Это является значительным плюсом.

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

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


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

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

-дублирующие работы;

-неэффективный документооборот.

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

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


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


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


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


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


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

В разрабатываемой мной системе реализация приложения выполнялась в MS Access 2003. В данном продукте компании Microsoft содержится ограниченный набор инструментариев создания информационной системы, но есть встроенный язык программирования - Visual Basic. Именно с помощью данного языка реализовывались те функции, которые должна была выполнять разрабатываемая система по требованию заказчика, но которые нельзя было выполнить встроенного набора инструментов MS Access 2003.

Ниже будут описаны основные функции системы:

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

-форма «Авторизации» (рисунок 3.2) состоит из текстовых полей, где нужно ввести свои логин и пароль и двух кнопок: далее и выход из программы. После правильной авторизации, при нажатии на кнопку «Далее» (програмный код кнопки «Далее» представлен в приложении Г рисунок Г.1), открывается форма на которой есть еще две кнопки (рисунок 3.4). Кнопка «Регистрация пенсионера» - форма регистрации пенсионера (рисунок 3.5). Программный код кнопки представлен в приложении Г рисунок Г.4. Кнопка «На главную», - позволяет вернуться для выхода из программы при нажатии на кнопку «Выход» (программный код кнопки представлен в приложении Г рисунок Г.2). «Расчет пенсии»(программный код кнопки представлен в приложении Г рисунок Г.5) позволяет перейти на форму «Расчет» для расчета пенсии (рисунок 3.6.). На всех этих присутствуют кнопки со своими кодами. Если пользователь неправильно ввел логин или пароль, программа выдает ошибку и повторную возможность ввода (рисунок 3.3.).

-на форме «Расчет» (рисунок 3.6) есть кнопка с названием одинаковым кнопкам всех форм «На главную», имеет идентичный код (программный код кнопки представлен в приложении Г рисунок Г.3). При нажатии на кнопку «Итоговые начисления» производится итоговый расчет пенсии (программный код кнопки представлен в приложении Г рисунок Г.6). А при нажатии на кнопку «Сформировать отчет» (рисунок 3.7) (программный код кнопки представлен в приложении Г рисунок Г.8) открывается форма «Отчет», где представлении четыре кнопки: «Итоговые начисления», «По месту жительства», «Расчет ИКП», для формирования отчетов и «Отправить по почте», для перевода отчетов в финансовые учреждения (программный код кнопки «Отправить по почте» представлен в приложении Г рисунок Г.9).


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


Рисунок 3.2 - Форма «Авторизация»


Рисунок 3.3 - Повторная авторизация


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

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


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

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


Рисунок 3.8 - Форма «Итоговые начисление»


Рисунок 3.9 - Отчет «По месту жительства»


Рисунок 3.10 - Отчет «Расчет ИКП»


Общий вид схемы данных системе предоставлен в приложении Д.

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


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

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

Примерами таких запросов могут послужить:

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

-получение суммы по набору строк в таблице;

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

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

В реализуемой мной системе были использованы следующие запросы на выборку:

-запрос на формирование отчета по начислению пенсии;

-запрос на расчет ИКП;

-запрос на формирование статистики по месту жительства пенсионеров.

Запрос на формирование отчета по начислению пенсии. Данный запрос формирует все необходимые данные для формирования отчета по начислениям. Результат запроса можно увидеть на рисунке 3.11. Программный код sql-запроса можно увидеть на рисунке Е.1 приложения Е.

Запрос на формирование статистики по месту жительства пенсионеров. Смысл данного запроса состоит в том, чтобы выбрать из таблицы «Оформление пенсионера», данные поля - Адрес прописки, и составить отчет по этому параметру. Результат запроса на рисунке 3.12. Программный код запроса на рисунке Е.2 приложения Е.

Запрос на формирование данных для составления отчета на расчет ИКП. Данный запрос выводит информацию благодаря которой можно сделать вывод о страховых взносах. Результат запроса на рисунке 3.13. Программный код sql-запроса показан на рисунке Е.3 приложения Е.

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


Рисунок 3.11 - Результат запроса «Итоговые начисления»


Рисунок 3.12 - Результат запроса «По месту жительства»


Рисунок 3.13 - Результат запроса «Расчет ИКП»


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


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

Из определения тестирования вытекает ряд принципов.

Принцип 1. Процесс тестирования более эффективен, если проводится не автором программы. Тестирования направленно на выявление ошибок поэтому, чем больше ошибок выявлено, тем эффективно прошло тестирование.

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

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

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

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

Принцип 5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.

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

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

Тестирование программы «Автоматизация места инспектора по начислению пенсии» методом «черного ящика». Тестирование проводилось вручную. При обнаружении ошибок система подвергалась доработке, а после доработки отправлялась опять на тестирование. Тестирование системы производилось частично.

Сначала был построен план тестирования, который состоит из четырех слагаемых:

-ввод входных данных;

-обработка запроса;

-формирование отчета;

-вывод отчета на экран.

Входными данными будет служить информация о пенсионере: ФИО, заработная плата за период 60 месяцев, ИКП, страховой стаж, стажевый коэффициент;

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

Тестирование.

Тест 1. Необходимо вывести результаты начислений в этом месяце. Результат отчета показан на рисунке 3.14.


Рисунок 3.14 - Результат теста по выводу итоги начисления пенсии


Тест 2. Необходимо вывести отчет по месту жительства.

Входными данными будут являться ФИО пациента и адрес проживания. Результат теста показан на рисунке 3.15.

Рисунок 3.15 - Отчет по месту жительства


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

Тест 3. Необходимо вывести отчет по расчету ИКП. Результат тестирования можно посмотреть на рисунке 3.16


Рисунок 3.16 - Отчет по расчету ИКП


На данной стадии тестирования, тест прошел успешно т.к. входные данные (ФИО пенсионера и ИКП) полностью совпадают с результатами выходных данных. Отчет по результатам тестирования представлен в таблице 3.1


Таблица 3.1 - Отчет по результатам тестирования системы

Тестируемая группа отчетовНомер тестаНазвание отчетаПоследовательность действийОжидаемый результатРезультат теста1Итоговые начисления Отображение отчета.отчет отобразился; запрос на выборку выполняется правильно.ОК2Отчет по месту жительстваОтображение отчета.отчет отобразился; запрос на выборку выполняется правильно.ОК3Отчет по расчету ИКПОтображение отчета.отчет отобразился; запрос на выборку выполняется правильно.ОК

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


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


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

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

Для работы разработанного мной программного продукта необходимо, чтобы в пенсионном фонде был установлен следующий программный продукт:Access 2003. Данный продукт входит в пакет Microsoft Office;

Технические требования, которые должны быть выполнены для работы системы «Автоматизированное место инспектора по начислению пенсии»:

-рабочая станция с процессором не ниже Pentium II;

-сетевая карта 100 Mb/s или выше;

-оперативная память не ниже 64 Mb;

-необходимое свободное место на жестком диске не менее 50 Mb.

План развертывания системы.

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


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


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



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


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


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

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

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

-каскадная модель, иногда также называемая моделью «водопад» (waterfall);

-спиральная модель.

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

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

Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»:

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

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

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

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

Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен:

-существенная задержка получения результатов;

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

-сложность распараллеливания работ по проекту;

-чрезмерная информационная перенасыщенность каждого из этапов;

-сложность управления проектом;

-высокий уровень риска и ненадежность инвестиций.

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

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

Рисунок 4.1 - Спиральная модель жизненного цикла информационной системы


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

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

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

Рассмотрим преимущества итерационного подхода более подробно:

-итерационная разработка существенно упрощает внесение изменений в проект при изменении требований клиента;

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

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

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

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

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

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

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

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

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

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

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

В таблице 4.2 представлены итоговые результаты процесса выбора модели жизненного цикла.


Таблица 4.2 - Определение оптимальной модели жизненного цикла в баллах

ХарактеристикаКаскаднаяV-образнаяПрототипированиеСпиральнаяRADИнкрементнаяТребования 225744Участники команды разработчиков328933Коллектив пользователей222514Типы проектов и рисков458946Итого 131123301217

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


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

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

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

-ускорении и упрощении распечатки отчетов;

-получении любой интересующей инспектора информации в течении нескольких секунд.

Для определения области действия программного продукта воспользуемся методикой «будет/не будет». Сформулируем цели для того, что понять каким будет, а каким не будет проект.

Будет:

-использоваться для приема и передачи данных;

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

-использовать мобильные технологии.

Не будет:

-использоваться в учебных целях;

-переносится на другие платформы;


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


Структура пооперационного перечня работ разрабатывалась в приложении Microsoft Office Project 2003/16/.

Эта структура включает следующие задачи и подзадачи, представленные на рисунке 4.3.


Рисунок 4.3 Структура поперечного перечня работ


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


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

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

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

-анализ существующих решений по автоматизации места инспектора;

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

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

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

-анализ и моделирование требований;

-спецификация требований;

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

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

-архитектурное проектирование;

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

-проектирование баз данных;

-обоснование выбора платформы создания ИС;

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

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

-реализация приложения;

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

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

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

-изменение кода продукта;

-повторное тестирование измененного кода;

Развертывание;

-закупка необходимого оборудования;

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

-установка и настройка оборудования;

-обучение персонала.

Наглядно ресурсы необходимые для реализации ИС автоматизации рабочего инспектора по начислению пенсии представлены на рисунке 4.4.


Рисунок 4.4 Ресурсы необходимые для реализации ИС


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


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

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

Сокращение объема работ по сопровождению ПО (decreased maintenance effort). Если кто-то разработал ПО, то он же отвечает и за его последующее развитие. Известен парадокс компетентного разработчика ПО: "чем больше вы работаете, тем больше работы вы себе создаете". Довольные пользователи вашей продукции начнут просить добавления новых функциональных возможностей, переноса на новые платформы. Единственное решение парадокса - стать некомпетентным разработчиком, - чтобы никто больше не был заинтересован в вашей продукции.

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

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

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

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

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

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

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

При управлении проектом необходимо обеспечено решение следующих задач:

-соблюдение оговоренных сроков окончания работ;

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

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

Поэтому в данном случае уместно использовать автоматизированное средство Microsoft Project являющееся широко распространённой системой управления проектами.

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

Управление проектами в пакете Microsoft Project 2003 первым шагом подразумевает построение календарного графика работ.

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

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

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


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


Оценка длительности и стоимости разработки программного обеспечения в пакете Microsoft Project 2003 производится на основе диаграммы Ганта (смотри приложение Ж). Диаграмма Ганта - это линейный график, задающий сроки начала и окончания взаимосвязанных работ, с указанием ресурсов, используемых для их выполнения /10/. Построенная диаграмма Ганта приведена в приложении Ж. Оценка длительности разработки ПО приведена на рисунке 4.5.


Рисунок 4.5 - Оценка длительности разработки ПО


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


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

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


Рисунок 4.6 - Список ресурсов


На рисунке 4.7 представлены трудозатраты ресурсов проекта.


Рисунок 4.7- Трудозатраты ресурсов проекта.


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


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

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

Центральным показателем в рассматриваемом методе является показатель NPV (net present value) - текущая стоимость денежных потоков за вычетом текущей стоимости денежных оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном измерении.

Управление Пенсионного фонда РФ ... рассматривает эффективность внедрения информационного проекта.

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

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

Расходы на проектирование включают в себя:

-расходы на лицензированное ПО MS Access = 20000 (рублей);

Расходы на оплату труда:

-разработчика = 5000;

-тестировщика = 2000;

-аналитика - консультанта = 3000;

-на обучение пользователей = 1000;

-на внедрение = 1000.

Расчет экономической эффективности проекта

Входные данные:

Срок, на который рассчитывается проект (кол-во мес n): 3 месяца.

Дополнительная прибыль от реализации проекта(DP): 30000р.

Ежемесячные затраты на реализацию проекта(Z1): 12000р.

Ежемесячные затраты на реализацию проекта(Z2): 12000р.

Ежемесячные затраты на реализацию проекта(Z3): 12000р.

Стартовые инвестиции (IC): 32000р.

Ставка дисконтирования (i): 1%.

Рассчитаем:

Чистый приведенный доход(net present value) является центральным показателем - текущая стоимость денежных потоков за вычетом текущей стоимости денежных оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном измерении. При разовой инвестиции расчет чистого приведенного дохода можно представить следующим выражением:


(4.1)


где - ежемесячные денежные поступления в течение n месяцев, определяются по формуле:



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

- ежемесячные затраты на реализацию проекта;

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

- ставка дисконтирования.

(руб.)

( 18000 / (1.01) + 18000 / (1.01)2 + 18000 / (1.01)3 )- 32000 = (17822 + 17645 + 17471) - 32000 = 20938

Коэффициент возврата инвестиций

Коэффициент возврата инвестиций ROI (Return of Investment) позволяет оценить прибыльность инвестиций, вложенных в проект.

Формула расчета:


(4.2)

где - чистый приведенный доход,

- стартовые инвестиции.

т.к - проект прибылен.

Срок окупаемости

Для анализа инвестиций применяют и такой показатель, как срок окупаемости (payback period method) - продолжительность времени, в течение которого дисконтированные на момент завершения инвестиций прогнозируемые денежные поступления равны сумме инвестиций. Иными словами - это сумма лет, необходимых для возмещения стартовых инвестиций:


(4.3)


т.е. = 0.

= Число лет до года окупаемости + (Не возмещенная стоимость на начало года окупаемости / Приток наличности в течение года окупаемости)

Рассчитаем дисконтированный денежный поток:


Период01 мес2 мес3 месДенежный поток- ICR1R2R3Дисконтированный денежный поток- ICR1/(1+i)R2/(1+i)2R3/(1+i)3Накопленный дисконт. денежный поток- IC NPV1NPV2NPV3Период0123Денежный поток-32000180001800018000Дисконтированный денежный поток-3200017821,7817645,328917470,6227Накопленный дисконтированный денежный поток-32000-14178,223467,1120937,73

= 2 + 1174,58 / 13161,44 = 2,19 мес

Срок окупаемости проекта составляет 2 месяца 19 дней.

Дисконтированный индекс доходности (рентабельности)

Индекс прибыльности (PI). Индекс прибыльности показывает, сколько мы заработаем денег с каждого вложенного рубля, и рассчитывается по формуле


(4.5)


Таким образом, индекс прибыльности равен:

= 1,65

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


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


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


Заключение


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

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

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

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

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

Извлечение всех необходимых пользователям разработанной информационной системы данных было осуществлено с помощью sql - запросов. В дипломной работе было произведено описание всех этих запросов.

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

Четвертая глава посвящена управлению разрабатываемым информационным проектом. Был произведен выбор жизненного цикла разработки данной информационной системы, обоснование выбора именно этого цикла. Выбор был сделан в пользу итерационной модели, так как следующий этап заканчивается только после завершения предыдущего, но также есть и возможность вернуться на предыдущий этап в случае обнаружения ошибок. Были выделены цели и область действия данного разрабатываемого продукта. Разработан пооперационный перечень работ выполняемых в ходе разработки и реализации данной системы. Были определены необходимые ресурсы для разработки и внедрения информационной системы, также было сделано распределение данных ресурсов. Также был осуществлен расчет экономической эффективности данного проекта. Работа была выполнена с использованием следующих программных продуктов: MS Access 2003, BPWin 4.0, ERWin 4.0, MS Project 2002, MS Word 2003, MS Excel 2003, MS Power Point 2003

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


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


1.Аглицкий Д.С., Аглицкий И.С. Российский рынок информационных технологий: проблемы и решения. - М.: 2000. ~ 208с.

.Акперов И. Г. Управление проектами: учебно-методический комплекс / И. Г. Акперов, В. А. Долятовский. - Ростов-на-Дону: ИУБиП, 1999.

.Андерсен, В Microsoft Access 2000: пер. с англ. / Вирджиния Андерсен. - М.: АСТ: Астрель,2005. - XXV, 641с.

.Администрирование Microsoft SQL Server 2000. Учебный курс MCSA/ MCSE, MCDBA/Пер. с англ. - 2-е изд., испр. - М.: Издательско-торговый дом «Русская Редакция», 2002. - 640 стр.: ил.

.Алехин 3. ITIL - основа концепции управления IT-службами / Открытые системы, № 3 (59), март 2001.

.Амблер, С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. / С. Амблер. - СПб.: Питер, 2005.

.Богданов, В. Управление проектами в Microsoft Project 2002 / В. Богданов. - СПб.: ПИТЕР, 2003.

.Баронов В.В. и др. Автоматизация управления предприятием. - М.: ИНФРА-М, 2000.- 239с.

.Виллариал Б.Программирование Access 2002 в примерах: Пер. с англ. -М.: КУДИЦ-ОБРАЗ, 2003. - 496 с.

.Вигерс, К. Разработка требований к программному обеспечению.: Пер. с англ. / К. Вигерс.:- М.: Издательско-торговый дом «Русская редакция», 2004.

.Вирджиния Андерсен «Microsoft Access 2003» пер. с англ.М.:АСТ:Астрель 2005; 678 стр

.Вендров А.М.. Проектирование программного обеспечения экономических информационных систем - М.: Финансы и статистика, 2002 - 448 с.

.Годин В.В. Управление информационными ресурсами: 17-модульная программа для менеджеров «Управление развитием организации». Модуль 17. - М.: ИНФРА-М, 1999.-432с

.Гультяев, А. К. MS Project 2002. Управление проектами. Русифицированная версия: Практическое пособие / А. К. Гультяев. - СПб.: КОРОНА принт, 2003.

.Дик В.В. Методология формирования решений в экономических системах и инструментальные среды их поддержки. - М.: Финансы и статистика, 2000. - 300с.

.Дж. Макконнелл Основы современных алгоритмов.2-е дополненное издание Москва:Техносфера, 2004. - 368с.

.Долятовский, В. А. Управление проектами. Учебное пособие. / В. А. Долятовский, В. Н. Долятовская. - Ростов-на-Дону: ИУБиП,2003.

.Избачков, Ю.С. Информационные системы. Учебник для вузов / Ю.С. Избачков, В.Н. Петров. 2-е изд. - СПб.: Питер, 2005.

.Информационные системы в экономике / учебник.- М.: Финансы и статистика, 1996. - 272с.

.Костров А.В. Основы информационного менеджмента: учебное пособие. - М.: Финансы и статистика, 2001. - 336 с.

.Колесников С.Н. Инструментарий бизнеса: современные методологии управления предприятием. - М.: Издательско-консультационная компания «Статус-Кво 97», 2001. -336с.

.Костров А.В. Введение в информационный менеджмент / учебное пособие. - Владимир: государственный технический университет, 1996. - 132с.

.Легард Д. Современная технология выбирает сетевые компьютеры / Computerworld, № 39, 1996.

.Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход: Пер. с англ. - М.: Издательский дом «Вильямс», 2002 - 448 с

.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. - М.: ДМК Пресс; М.: Компания АйТи, 2003. - 224с

.Маклаков, С.В. BPwin и ERwin. CASE - средства разработки информационных систем. Учебник / С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000.

.Маклаков, С. В. Создание информационных систем с AllFusion Modeling Suite / С. В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2003.

.Магрегор, Д. Тестирование программного обеспечения. Практическое пособие / Д. Сайкс. - Киев.: ООО «ТИД «ДС»», 2002.

.Мацяшек, Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ./ Л. А. Мацяшек. - М.: Издательский дом «Вильямс», 2002.

.Просиз Дж Программирование для Microsoft .NET /Пер. с англ. - М.: Издательско-торговый дом «Русская Редакция», 2003. - 704 стр.: ил.

.Скрипкин К.Г. Экономическая эффективность информационных систем. - М.: ДМК Пресс, 2002.-256с

.Смирнова, Г. Н. Проектирование экономических информационных систем: Учебник / Г.Н. Смирнова, А.А. Сорокин / Под ред. Ю.Ф. Тельнова. - М.: Финансы и статистика, 2003.

.Соммервилл, Иан. Инженерия программного обеспечения.: Пер. с англ. / Иан Соммервилл. 6-е изд. - М.: Издательский дом «Вильямс», 2002.

.Тютюнник А.В., Шевелев А.С. Информационные технологии в банке. - М.: Издательская группа "БДЦ-пресс", 2003. - 368с.

.Устинова Г.М. Информационные системы менеджмента: Основные аналитические технологии в поддержке принятия решений / учебное пособие. - СПб: Издательство «ДиаСофтЮП», 2000. - 368с

.Управление проектами в Microsoft Project: Учебный курс (+ CD) / В. В. Богданов. - СПб.: Питер, 2003. - 640 с.: ил.

.Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер. - М.: Издательский дом Вильямс, 2003.

.Форта, Бен.Освой самостоятельно SQL. 10 минут на урок, 3-е издание. :Пер. с англ. - М. : Издательский дом "Вильяме", 2005,- 288 с.

.Хаммер М., Чампи Д. Реинжениринг корпорации: манифест революции в бизнесе. - СПб: Издательство Санкт-Петербургского университета, 1999.

.Хендерсон, К. Профессиональное руководство по SQL Server: хранимые процедуры, XML, HTML (+CD) / К. Хендерсон. - СПб.: Питер, 2005.

.Ховард М., Лебланк Д. Защищенный код: Пер. с англ, - 2-е изд., испр. М.: Издательско-торговый дом «Русская Редакция», 2004. - 704 стр.: ил.

.Шеер, А.В. Бизнес - процессы. Основные понятия. Теория. Методы. Учебное пособие / А.В. Шеер / Под ред. М.С. Каменовой. - М.: Весть - Метатехнология, 1999.

.Школин, А. Легковесная автоматизация. IT - системы для небольших предприятий //Финанс. - 2005. №15. - С. 56 - 61. (Журнал)

.Шафер, Дональд. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. - М.: Издательский дом Вильямс, 2004. - 1136 с.: ил.

.Эрик, Дж. Проектирование баз данных с помощью UML. Учебное пособие / Дж. Эрик, А.М. Роберт - СПб.: Издательский дом "Вильямс", 2002.

.Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. - СПб.: Питер, 2002. - 496с.



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


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



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



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


Рисунок Г.1 - Программный код кнопки «Далее» в форме «Главная»


Рисунок Г.2 - Программный код кнопки «Выход» в форме «Главная»


Рисунок Г.3 - Программный код кнопки «На главную»


Рисунок Г.4 - Программный код кнопки «Регистрация пенсионера»


Рисунок Г.5 - Программный код кнопки «Расчет пенсии»


Рисунок Г.6 - Программный код кнопки «Итоговые начисления»


Рисунок Г.7 - Программный код кнопки «Расчет ИКП»


Рисунок Г.8 - Программный код кнопки «Сформировать отчет»


Рисунок Г.9 - Программный код кнопки «Отправить по почте»


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



Рисунок Д.1 Схема данных автоматизированной информационной системы


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


Рисунок Е.1 - Программный код sql-запроса «Итоговые начисления»


Рисунок Е.2 - Программный код sql-запроса «По месту жительство»


Рисунок Е.3 - Программный код sql-запроса «Расчет ИКП»


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




Разработка автоматизированного рабочего места инспектора по начислению пенсии РЕФЕРАТ Дипл

Больше работ по теме:

Проектирование автоматизированного рабочего места менеджера в агентстве недвижимости
Диплом
Разработка приложения с использованием ОреnGL для построения динамического изображения трехмерной модели объекта "Мотоцикл"
Диплом
Автоматизация документооборота агентства недвижимости
Диплом
Разработка информационной системы деятельности отдела гарантийного ремонта товаров фирмы "Народная торговая компания"
Диплом
Основы безопасности программного обеспечения
Диплом

Предмет: Информационное обеспечение, программирование

Тип работы: Диплом

найти  

ПОИСК

Новости образования

Российский государственный социальный университет реорганизует сеть своих филиалов
22 Июля 2016 16:26
Более 70 представителей крупных вузов АСЕАН подтвердили участие в форуме во Владивостоке
22 Июля 2016 12:51
Абызов: публикация первичных статсведений снизит бюрократическую нагрузку на школы
22 Июля 2016 11:53
В Чечне свыше 200 школьников сдали ЕГЭ с результатом свыше 90 баллов - министр
22 Июля 2016 05:36
Замглавы Минобрнауки РФ: задача сократить число людей с высшим образованием не стоит
21 Июля 2016 20:19

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ