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

Введение

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

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

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

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

Целью написания дипломного проекта является разработка системы электронного документооборота банка «ВТБ 24». Для достижения поставленной цели необходимо решить следующие задачи:

1. Анализ предметной области и обоснование проектных решений.

2. Проектирование структуры базы данных и интерфейса системы.

3. Разработка и тестирование автоматизированного рабочего места сотрудника канцелярии банка.

4. Обоснование экономической эффективности разработки.

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



1. Аналитическая часть

канцелярия банк база данные

1.1 Технико-экономическая характеристика предметной области

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

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

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

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

Основными целями канцелярии являются:

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

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

- координация видов работ с документами;

- контроль за последовательностью работы с документами;

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

Выполнение этих целей предусматривает решение следующих задач:

- постоянное совершенствование форм и методов работы с документами;

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

- сокращение документооборота;

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

Функции канцелярии:

1. Разработка и проектирование бланков документов.

2. Осуществление экспедиционной обработки поступающих и отправляемых документов.

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

4. Организация своевременного рассмотрения и подготовки к докладу руководству поступающих документов.

5. Контроль за правильностью оформления документов, представляемых на подпись руководству.

6. Регулирование хода исполнения документов, контроль прохождения, оформления и исполнения документов в установленный срок.

7. Организация машинописного (компьютерного) изготовления текстов документов, их копирования и оперативного размножения.

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

9. Организация и ведение делопроизводства по предложениям, заявлениям, жалобам граждан.

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

12. Контроль за выполнение условий труда сотрудников канцелярии.

Все функции, права, обязанности и ответственность сотрудников канцелярии в определенной форме закреплены в должностной инструкции, которая разрабатывается отделом кадров банка. [19]

1.2 Экономическая сущность комплекса экономических информационных задач

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

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

Одним из примеров таких методик моделирования является IDEF. IDEF0 основана на ранее разработанной Дугласом Т. Росс методике моделирования SADT. Построение SADT - модели начинается с представления всей системы в виде простейшего компонента - одного блока и дуг, изображающих интерфейсы с функциями вне системы (контекстной диаграммы).

Контекстная диаграмма процесса выполнения ремонта представлена на рисунке 1.1.

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

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

Рисунок 1.1. Контекстная диаграмма процесса

Рассмотрим более подробно деятельность по канцелярии. Для этого выполним декомпозицию контекстной диаграммы (рисунок 1.2).



Рисунок 1.2. Декомпозиция процесса в нотации IDЕF0

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

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

Целью дипломного проекта является разработка АРМ электронного документооборота канцелярии банка.

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

1.3.1 Обоснование выбора задач, входящих в комплекс

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

- руководителю банка;

- в структурные подразделения, не требующие резолюции руководителя.

Все входящие документы делятся на:

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

-нерегистрируемые:

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

- корреспонденция с пометкой «лично»;

- документы, поступающие в адрес общественных организаций;

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

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

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

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

- договора, повестки - приглашения правоохранительных органов.

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

При рассмотрении документа руководителем пишется резолюция, которая содержит решение по существу поставленного в документе вопроса. В резолюции определяется ФИО исполнителя, четкие и конкретные указания по исполнению, срок исполнения, подпись, дата. [15]. Процесс обработки входящих документов представлен на рисунке 1.3.



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

Рисунок 1.3. Процесс обработки входящих документов



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

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

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

Процесс обработки исходящих документов представлен на рисунке 1.4.



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

Рисунок 1.4. Процесс обработки исходящих документов

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

Канцелярия составляет следующие виды отчетов:

- Отчет о входящих документах;

- Отчет о документах, числящихся за исполнителями, т.е. находящихся на контроле;

- Отчет о выполненных документах;

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

- Отчет о невыполненных входящих документах;

- Отчет о внутренних документах.

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

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

- автоматическая регистрация документа. Занесение в регистрационно-контрольную карточку сведений о документе;

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

- возможность внесения изменений или удаления документа;

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

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

- автоматическое формирование типовых отчетов;

- ведение и использование различных справочников.

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

Сокращение времени на обработку информации.

2. Увеличение объемов обработки информации.

3. Сокращение времени поиска документов и подготовки отчетов.

4. Уменьшение количества ошибок и повышение качества обработки документации.

5. Повышение технического уровня и коэффициента использования вычислительных средств.

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

7. Повышение информированности руководства за повышения полноты и достоверности отчетов.

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

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

1.3.2 Обоснование проектных решений по информационному обеспечению комплекса задач

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

Обоснование проектных решений по информационному решению включает следующие пункты:

- обоснование состава и содержания входных и выходных документов, метода их построения;

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

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

- обоснование состава и способов организации файлов с результатной и промежуточной информацией.

Формы ввода должны быть реализованы в удобном для пользователя виде и позволять изменять любые хранимые данные.

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

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

Обоснование способа организации информационной базы.

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

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

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

СУБД можно классифицировать по ряду признаков:

· модель данных,

· тип программного обеспечения;

· характер использования.

Классификация в соответствии с моделью данных

На практике большинство применяемых СУБД используют одну из трех мoделей данных: реляционную, иерархическую или сетевую.

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

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

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

В сетевой модели данных понятие главнoго и подчиненных объектов несколько шире. Любой объект может быть и главным, и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный - термином «член набора»). Один и тoт же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это значит, что каждый объект может участвовать в любом числе взаимосвязей.

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

Кроме вышеперечисленных «классических», в последние годы появились и стали активно внедряться следующие модели данных: постреляционная, многомерная и объектно-ориентированная.

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

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

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

Сервер БД представляет собой программное обеспечение, которое реализует функции управления базами данных на основе запросов, формируемых другими программами (клиентами БД). Языком запросов обычно выступает SQL (StructuredQueryLanguage - структурированный язык запросов).

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

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

По характеру использования СУБД делят на персональные и многопользовательские.

Персональные СУБД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательских СУБД. К числу персональных СУБД относятся MS Access, VisualFoxPro, Paradox, Clipper и др.

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

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

Для реализации данной системы выбрана СУБД MicrosoftSQLServer версии 2008. Такой выбор обоснован тем, данная СУБД уже установлена и успешно работает на предприятии.



1.3.3 Обоснование проектных решений по информационным технологиям, применяемым для решения комплекса задач

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

Стадии жизненного цикла (далее ЖЦ) описаны в Государственном стандарте РФ ГОСТ Р ИСО/МЭК "Информационная технология. Процессы жизненного цикла программных средств"под номером 12207-99, принятый и введенный в действие постановлением Госстандарта России от 23 декабря 1999 г. № 675-ст. Настоящий стандарт содержит полный аутентичный текст международного стандарта ISO/IEC 12007:95 «Информационная технология. Процессы жизненного цикла программных средств», который действует с незначительными поправками в настоящее время и регламентирует процессы жизненного цикла программных средств и информационных технологий. Все процессы ЖЦ в соответствии с этим стандартом делятся на три группы: основные процессы, вспомогательные и организационные.

Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами [2]. Стандарт не определяет конкретной модели жизненного цикла или метода разработки программного средства. Пользователи, применяющие настоящий стандарт, должны сами выбирать модель ЖЦ применительно к своему программному проекту и распределять процессы, работы и задачи, выбранные из настоящего стандарта, на данной модели [6].

ГОСТ 34.60190 определяет следующие стадии и этапы создания АИС:

1. Формирование требований к АИС:

- обследование организации и обоснование необходимости разработки ИС;

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

- оформление отчёта о проделанной работе (тактико-техническое задание).

2. Разработка концепции АИС:

- изучение объекта автоматизации;

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

- разработка вариантов АИС, выбор окончательного варианта, который будет удовлетворять всем требованиям пользователя;

- оформление отчёта о проделанной работе.

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

4. Эскизный проект (макет):

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

- разработка документаций как на АИС.

5. Технический проект:

- принятие решений по создаваемой системе;

- разработка документаций на систему;

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

- оформление технических требований на разработку изделий для комплектования АИС;

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

6. Рабочая документация:

- создание рабочей документации;

- разработка программ и её адаптация.

7. Ввод в действие:

- подготовка предприятия-заказчика к началу установки ИС;

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

- комплектование АИС техническими и программными средствами;

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

- предварительные испытания ИС;

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

- приёмочные испытания.

8. Сопровождение АИС:

- выполнение обязательств по гарантийному обслуживанию;

- послегарантийное обслуживание.

Модель жизненного цикла отражает различные состояния системы в процессе всего жизненного цикла ИС. Модель ЖЦ - это такая структура, которая содержит все процессы, действия и задачи по разработке программного продукта, по его сопровождению и функционированию в течении всей жизни созданной системы, вплоть до её исчезновения [2].

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

- Планирование и анализ требований.

- Проектирование (техническое и логическое.).

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

- Внедрение (Тестирование, опытная эксплуатация. Обучение персонала).

- Эксплуатация (Сопровождение и модернизация. Исправление ошибок и недоработок. Повторение стадий 2-5 при необходимости). [3]

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

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

- анализ (планирование и требования);

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

- разработка (кодирование);

- обзор (тестирование).

Рисунок 1.5. V-образная модель ЖЦ ИС

Особое внимание уделяется верификации и аттестации программного продукта. Тестирование обсуждается и планируется, начиная с ранних этапов ЖЦ разработки. Основные понятия в данной модели:

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

- кодирование - преобразование алгоритма в готовое программное обеспечение (далее ПО);

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

- интеграционное тестирование - интеграция программного продукта (далее ПП) и его тестирование;

- системное тестирование - проверка функционирования ПП после помещения его в аппаратную среду [5].

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

1.3.4 Обоснование проектных решений по программному обеспечению комплекса задач

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

Основным отличием системы «1С: Предприятие 8.2» как и других ERP-систем является разделение метаданных и данных и представление системой способа управления данными при помощи метаданных и специального языка работы с данными. Это позволяет в рамках системы «1С: Предприятие 8.2» создавать прикладные решения - конфигурации.

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

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

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

Рисунок 1.6. Структура технологической платформы 1С: Предприятие

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

- Разработан механизм поставки и поддержки конфигураций.

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

- Разработана унифицированная объектная модель системы..

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

- У справочников, документов и других объектов конфигурации поддерживаются табличные части.

- Расширен набор элементов управления, их свойств и событий.

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

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

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

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

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

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

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

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

Платфoрма изолирует разработчика от низкоуровневого программирования. Разработчик не обращается к базе данных напрямую, а манипулирует объектами, командами встроенного языка и запросов. Платформа сама транслирует их в соответствующие команды SQL-сервера в случае клиент-серверного варианта работы или команды собственной СУБД для файлового варианта.

Возможность использования файлового или клиент-серверного варианта работы позволяет адаптировать решение для конкретного пользователя в зависимости от объема задачи. Данные работы представлены на рисунках 1.7 и 1.8.

Рисунок 1.7. Файловый вариант работы

Рисунок 1.8. Клиент-серверный вариант работы

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

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

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

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

- Документы, предназначенные для фиксации событий;

- Механизм характеристик, предназначенный для организации хранения свойств объектов, не известных на момент разработки;

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

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

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

- Бизнес-процессы, позволяющие описывать, создавать и управлять выполнением бизнес-процессов;

- Средства построения отчетов, которые позволяют создавать разнообразные отчеты;

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

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

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

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

Состав средств разработки системы 1С:Предприятие представлен на рисунке 1.9.

Рисунок 1.9. Состав средств разработки

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



2. Проектная часть

2.1 Информационное обеспечение комплекса задач

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

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

Информационная модель данных уровня сущностей «анализ результатов финансовой деятельности» показан на рисунке 2.1.

Рисунок 2.1. Информационная модель уровня сущностей



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

Рисунок 2.2 - Информационная модель «Сущность-связь» (уровень атрибутов).

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

1. Каждая сущность становится таблицей. Названия таблиц задаются во множественном числе.

2. Каждый атрибут сущности становится столбцом таблицы.

3. Ключевой атрибут становится ключом таблицы.

4. Связи между сущностями становятся связями между таблицами.

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

Рисунок 2.6. Физическая модель данных

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

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

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

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

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

Определим атрибуты первичных документов (таблицы 2.1, 2.2).

Таблица 2.1. Регистрационная карточка входящего документа

№ атрибута	Название поля
1	Регистрационный номер
2	Регистрационная дата
3	Исходящий номер
4	Исходящая дата
5	Код вида документа
6	Откуда
7	Краткое содержание
8	ФИО исполнителя
9	Дата исполнения
10	Исполнен
11	Номер исходящего документа
12	Дата исходящего документа
13	Ссылка на документ

Таблица 2.2. Регистрационная карточка исходящего документа

№ атрибута	Название поля
1	Регистрационный номер
2	Регистрационная дата
3	Куда
4	Краткое содержание
5	ФИО исполнителя
6	Вид отправления
7	Копия
8	Номер входящего документа
9	Ссылка на документ

Определим атрибуты справочников, которые будут использоваться в дипломном проекте (таблица 2.3)

Таблица 2.3. Справочник «Тип документа»

№ атрибута	Название поля
1	Код вида документа
2	Вид документа

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

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

Структура журнала регистрации входящих документов представлена на рисунке 2.7.

Рисунок 2.7. Журнал входящих документов

Структура журнала регистрации исходящих документов представлена на рисунке 2.8.



Рисунок 2.8. Журнал исходящих документов

Структура регистрационно-контрольной карточки документа представлена на рисунке 2.9.

Рисунок 2.9 Структура регистрационно-контрольной карточки

Структура отчета об объеме документооборота представлена на рисунке 2.10.

Рисунок 2.10 Отчет об объеме документооборота

Структура сводки об исполнении документов представлена на рисунке 2.11.



Рисунок 2.11 Отчет об объеме документооборота

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

2.2 Технологическое обеспечение

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



Рисунок 2.12 - Схема технологического процесса сбора информации



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

Рисунок 2.13 - Схема технологического процесса обработки информации

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

Рисунок 2.14 - Схема технологического процесса выдачи результатной информации в ИС

Технологическая операция - основная единица работы, выполняемая определенным исполнителем, которая:

? подразумевает четко определенную ответственность исполнителя,

? дает четкий результат, базирующийся на определенных исходных данных,

? имеет жестко определенные границы.

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

2.3 Программное обеспечение комплекса задач

2.3.1 Общие положения

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

- Подсистема «База данных» - эта подсистема представляет собой базу данных, в которой хранятся все данные (серверная часть).

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

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

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

1. Регистрация документов (входящих и исходящих).

2. Просмотр документов (входящих и исходящих).

3. Работа со справочниками.

4. Подготовка отчетов

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



Рисунок 3.1. Дерево функций

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

Пользовательский интерфейс представляет собой совокупность программных и аппаратных средств, обеспечивающих взаимодействие пользователя с компьютером. Основу такого взаимодействия составляют диалоги. Под диалогом в данном случае понимают регламентированный объем информацией между человеком и компьютером, осуществляемый в режиме реального времени и направленный на решение какой-либо задачи. Обмен информацией осуществляется передачей сообщений и управляющих сигналов. Сообщения - это порция информации, участвующая в диалоговом обмене [24, c.84].

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

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

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

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

4. Особенности памяти. Одновременно человек способен воспринимать и запоминать от 5 до 9 несвязанных объектов [24, c.89].

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

1. Определение требований пользователя к интерфейсу и типа интерфейса.

2. Определение сценариев использования интерфейса.

3. Проектирование.

4. Реализация (программирование и тестирование).

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

1. Разграничение доступа для разных групп пользователей.

2. Возможность выбора действий (функций) с объектами предметной области.

3. Удобство и простота в использование.

4. Интуитивная понятность и быстрота освоения.

5. Использование эргономичных цветов и расположения элементов на форме.

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

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

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

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

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

2. Объектно-ориентированные - интерфейсы прямого манипулирования, предполагают выбор и перемещение пиктограмм, соответствующих объектам предметной области[6, c.102].

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

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

Рисунок 3.2 Дерево вызова программных модулей

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



2.3.2 Описание программных модулей

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

Рисунок 3.3. Главное окно конфигурации

Справочник «Организации» предназначен для хранения информации об организации (рисунок 3.4).

Рисунок 3.4. Справочник «Организации»

При создании новой организации нужно заполнить поля «Наименование», «Полное наименование», а также вкладки «Адреса и телефоны», «Реквизиты». При заполнении адресов можно воспользоваться адресным классификатором. Организации может быть несколько (рисунок 3.5).



Рисунок 3.5. Справочник «Организации»

Справочник «Подразделения» представляет собой иерархическую структуру отделов предприятия (рисунок 3.6).

Рисунок 3.6. Справочник «Подразделения»

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