Реферат: Разработка системы по сбору информации
"Интегратор 3.0" состоит из следующих подсистем: денежные средства (касса, банк); дебиторы и кредиторы; материалы, продукция, товары, МБП; поставщики и подрядчики; основные средства и нематериальные активы; производственные затраты; покупатели и заказчики; прибыль, налоги, капитал; финансовая отчетность.
При разработке использовалась СУБД Clipper 5.2. В сетевом варианте базовой является конфигурация "файл-сервер". Для работы в архитектуре клиент/сервер необходимо дополнительно установить ПО Advantage Xbase Server. "Интегратор" эксплуатируется в сетях NetWare 3.xx и выше, Windows NT, LANtastic и др. Не рекомендуется применение ОС NetWare 4.01. Требования к аппаратному обеспечению: для станции-клиента необходимы процессор класса 486DX2 и 8 Мбайт оперативной памяти; для сервера - процессор не ниже Pentium 75 и ОЗУ объемом от 16 Мбайт.
2. Описание автоматизируемых функций
Цель создания системы: обеспечить выполнение требования законодательства в отношении отчетности по подоходному налогу.
Предназначения системы:
· учет начисленной заработной платы на предприятии, прочих доходов и удержанного подоходного налога;
· ведение различной статистики по оплате труда, как в объединении “СургутГазПром” в целом, так и в каждом подразделении отдельно;
· выдача необходимых отчетов в налоговую инспекцию, как на магнитных, так и на бумажных носителях;
· заполнение справок.
Предполагается, что система будет использоваться в следующих отделах предприятия:
· отдел налоговой политики;
· отдел ОТиЗ.
2.1. Анализ существующей системы функционирования и задачи автоматизации
В настоящее время объединение “СургутГазПром” состоит из тридцати трех структурных подразделений – предприятий второго звена, которые в свою очередь имеют в своем подчинении мелкие предприятия, участки. Все эти подразделения географически распределены по Сургуту, Сургутскому району, Тюменской области. В каждом отдельном подразделении есть свои управляющие структуры (директор, заместители и т.д.). Столь разветвленная структура, вызванная исключительно производственной необходимостью, имеет ряд неудобств в части централизованного планирования и управления. В интересующей нас части, это привело к тому, что в различных структурных подразделениях установлено различное программное и техническое обеспечение, разработаны разные системы кодирования информации, отсутствует единая база данных, различные формы внутренних отчетов. Только в конце 1998 года была сделана попытка, перевести все подразделения на работу с едиными классификаторами. В частности введен единый классификатор видов начислений и удержаний, разработанный отделом охраны труда и заработной платы. Также разрабатываются единые справочники должностей и профессий.
В месте с тем, несмотря на такую разобщенность, СургутГазПром вынужден отчитываться перед налоговой инспекцией как единое целое.
До 1999 года все отчеты о доходах работниках, удержанном подоходном налоге подготавливались и сдавались на бумажных носителях. Однако, в настоящее время, в связи с изменениями в законодательстве, о которых шла речь во введении, это стало невозможно.
В данный момент предоставлять отчет на магнитных носителях представляет проблему в связи с выше изложенной ситуацией.
Также не представляется возможным ведение единой базы из-за программного обеспечения различных фирм, большой территориальной распределенности и огромного объема информации, с которым применяемая СУБД работать просто не в состоянии (за один год только по одному структурному подразделению накапливается информация объемом более 140 Мбайт).
В этих условиях было принято решение об автоматизировании работы отделов налоговой политики объединения.
Схема представленная на рисунке 1 отражает потоки информации в процессе производства отчетности в ГНИ РФ. По мере надобности, но не реже одного раза в месяц, подразделения передают необходимую для расчёта подоходного налога информацию в отдел налоговой политики центрального офиса предприятия, где эти данные консолидируются и проверяются, после чего готовится отчётность для ГНИ РФ. Также к этим данным имеет доступ отдел ОТиЗ для получения необходимых ему отчетов по заработной плате.
Задачей решаемой разработанной системой является автоматизация этих процессов.
2.2. Состав функций реализуемых системой
· сбор информации о начисленной работникам заработной плате и об удержанном подоходном налоге ото всех структурных подразделений Газпрома;
· передача информации от удаленных рабочих станций на сервер через электронную почту, непосредственное соединение по модему, либо подготовка информации для передачи посредством магнитных носителей;
· проверка корректности полученной информации (правильности удержания подоходного налога);
· формирование собственной базы, выдаче всех требуемых отчетов и справок в налоговую инспекцию, как на магнитных, так и на бумажных носителях, на основе информации и базы данных, согласно действующему законодательству РФ;
· формирование и выдача внутренних отчетов;
· численность работников подразделений, размер средней заработной платы;
· динамика изменений численности работников, средней заработной платы;
· динамика % и численности работников, находящихся на больничном;
· динамика % и численности работников находящихся, в очередных отпусках;
· выдача прочих внутренних отчетов;
· ручной ввод информации о заработной плате и заполнение справок в налоговую инспекцию для физических лиц;
· обеспечение сервисных функций, как то: оптимизация базы данных, ведение архивов за “закрытые” годы, резервное копирование данных и их восстановление, блокнот, калькулятор, календарь;
· обеспечение защиты данных от несанкционированного доступа.
2.3. Решение по структуре системы
Структурно система состоит из рабочей станции и серверной части.
В функции серверной части должно входить:
· хранение, оптимизирование и поддерживание в рабочем и актуальном состоянии базу данных;
· обрабатывание запросы пользователей;
· обеспечение защиты данных от несанкционированного доступа.
В функции рабочих станций входит:
· обеспечение сбора, импорта информации, непосредственно из программ ее формирующих;
· проверка корректности собранной информации;
· передача информации серверу;
· формирование запросов к серверу;
· выдача справок и отчетов;
· поддержка сервисных функций, обеспечение дружественного интерфейса пользователя.
2.4. Решение по функциональному разбиению системы на модули
Функционально АРМ на рабочей станции состоит из следующих модулей:
· модуль импорта, занимающийся выборкой информации из баз данных АРМов расчета заработной платы и ее импортом в собственную базу;
· модуль справочников, предназначенный для корректировки и показа справочников системы (справочник профессий, должностей, цехов, участков, регионов и т.д.);
· рабочий модуль, предназначен для ввода/просмотра информации, получения различных отчетов;
· контролирующий модуль, занимающийся контролем достоверности и целостности информации, а также правильности удержания подоходного налога с физических лиц;
· модуль администратора, предназначенный для корректировки системной информации путей доступа и т.п.
В данном разделе рассмотрены:
· решения по мерам, для сохранения целостности баз и предотвращения несанкционированного доступа;
· выбор операционной среды и средств разработки;
· решения по комплексу технических средств;
· информационное обеспечение разработки.
3.1. Обеспечение защиты баз данных
Система обеспечивает защиту от несанкционированного доступа на чтение, запись и корректировку части информации, хранящейся в ней. Для доступа на изменение в базе служебной информации предусмотрен пароль администратора. Также введено разграничение доступа между рабочими станциями, каждая из них работает только со своими данными.
Для сохранения информации при перерывах во внешнем электропитании предусмотрены следующие меры:
· ведение журнала транзакций, что позволяет в случае нарушения структуры баз произвести откат транзакции;
· максимальное сокращение времени, в течение которого рабочие файлы открыты на запись, т.е. при необходимости обновить файл, он открывается на запись, обновляется и сразу же закрывается. При этом удается исключить ситуацию, когда файл открыт длительное время;
· периодическое резервное копирование базы;
· настоятельная рекомендация в руководстве пользователя и программиста, установить UPS на сервер.
3.2. Выбор операционной среды и средств разработки
Выбор в качестве операционной среды для функционирования АРМа платформы win32 (ей соответствуют операционные системы Windows95, Windows98, Windows NT) обусловлен следующими ее особенностями:
· ориентация заказчика на эту платформу;
· развитые средства создания пользовательского интерфейса;
· достаточная масштабируемость, т.е. способность работать на широком диапазоне компьютерного оборудования, начиная от машин уровня 486DX4‑100 до многопроцессорных систем;
· наличие драйверов для поддержки широкого спектра периферийных устройств (видеоадаптеров, сетевых адаптеров, принтеров, дисководов CD-ROM и пр.);
· чрезвычайно широкое распространение этой платформы;
· приемлемая для задач такого уровня надежность и производительность программ, работающих с использованием механизма вытесняющей многозадачности.
Из недостатков данной платформы, существенных для предлагаемой разработки, стоит отметить следующие:
· отсутствие в операционных системах Windows95 и Windows98 средств обеспечения безопасности и защиты от несанкционированного доступа, что вынуждает разрабатывать собственные или использовать сторонние модули для этого. В Windows NT этот недостаток частично устранен, однако по-прежнему нет поддержки шифрации хранимых данных;
· высокая требовательность к аппаратным ресурсам компьютера, что вынуждает использовать более мощные аппаратные платформы.
Выбор в качестве среды разработки пакета Borland Delphi 4 обусловлен следующими его особенностями:
· политика предприятия в области разработки ПО;
· возможность повторного использования готовых программных компонент;
· наличие большого количества стандартных компонент, а также достаточное количество библиотек компонент от сторонних фирм, расширяющих и дополняющих возможности стандартных;
· возможность генерации кода под платформу win32;
· поддержка технологий ActiveX, OLE, COM, CORBA, InterNet-технологий;
· достаточно высокая скорость и надежность работы скомпилированных программ в сравнении с интерпретирующими системами;
· ориентация на “визуальные” методы разработки программ, что позволяет быстро и качественно спроектировать и реализовать стандартный пользовательский интерфейс;
· перспективность, популярность и широкая распространённость данной среды разработки в мире.
Выбор в качестве СУБД разработки InterBase v. 5.0. обусловлен следующими его особенностями:
· после включения его в состав Delphi Client/Server Suite InterBase стал “родным” для Borland (ныне Inprise Corporation), а средства разработки приложений этой компании давно зарекомендовали себя с положительной стороны. Уже то, что он очень активно используется в государственном и военном секторе США говорит в его пользу;
· InterBase весьма прост в настройке и в администрировании по сравнению с другими SQL серверами;
· InterBase обладает отличными техническими характеристиками:
· размер базы данных до 20 Гбайт;
· максимальное число таблиц в одной БД 65536;
· максимальное число полей в одной таблице 1000;
· максимальное количество записей в одной таблице не ограничено;
· максимальная длина записи 64К (не считая полей BLOB);
· максимальная длина поля 32К (кроме полей BLOB – не ограничена);
· максимальное количество индексов в одной БД 65536.
Дополнительно в процессе разработки применялись следующие программные пакеты и инструментальные средства:
Пакет InstallShield Express – для создания комплекта дистрибутивных дискет.
Для подготовки документации, рекламного листа и демонстрационной версии программ использовались программы, входящие в комплект Microsoft Office 97.
3.3. Решения по комплексу технических средств
3.3.1. Выбор критериев отбора технических средств
Среди всего множества критериев отбора ТС нас интересуют:
· достаточный объем оперативного запоминающего устройства;
· достаточный объем накопителя на жестком магнитном диске;
· приемлемый тип видеоадаптера и дисплея для работы пользователя;
· достаточная производительность центрального процессора;
· наличие возможности вывода информации на бумажный, магнитный носитель;
· достаточная скорость передачи данных в ЛВС;
· приемлемая стоимость составляющих комплекса технических средств.
3.3.2. Расчет необходимых ресурсов, для функционирования системы, выбор ТС
Объем необходимого ОЗУ рассчитывается, исходя из размеров памяти, занимаемой загружаемой операционной системой, из необходимого объема памяти, выделяемого под драйверы для обслуживания ЭВМ, программы-оболочки, основного загружаемого модуля программного комплекса, динамических библиотек, подгружаемых по мере выполнения программы и резерва памяти для обработки информации.
Исходя из вышеизложенного, приходим, что для нормальной работы серверной части системы необходимо не менее 64 Мбайт ОЗУ (128 Мбайт рекомендуется). По современным понятиям, это уже не слишком высокое требование объясняется тем, что для нормальной работы выбранной в качестве ОС серверной части системы Windows NT v. 4.0 необходимо не менее 32 Мбайт оперативной памяти. Кроме того, учитывая большой объем базы данных, более 100 Мбайт и возможность многопользовательского доступа для оперативной работы сервера потребуется еще не менее 32 Мбайт ОЗУ.
