Разработка автоматизированного рабочего места менеджера системы Клиент-Банк

/

• 1. Анализ предметной области
• 1.1 Описание организации
• 1.2 Выбор технологии и метода проектирования
• 1.3 Задачи, подлежащие автоматизации
• 1.4 Анализ рынка программных средств
• 1.5 Выбор технических и программных средств
• 1.5.1 План помещения
• 1.5.2 Спецификация технических и программных средств
• 1.5.3 СУБД
• 2. Моделирование ИС
• 3. Постановка задачи
• 3.1 Организационно-техническая сущность комплекса задач
• 3.2 Описание входной и выходной информации
• 3.3 Описание входной информации
• 4. Проектирование базы данных
• 4.1 Проектирование инфологической модели сущность-связь (концептуальное проектирование)
• 4.2 Выбор СУБД
• 4.3 Даталогическое проектирование, определение типов и размеров атрибутов
• 4.4 Создание и разработка базы данных
• 4.5 Поддержка целостности данных
• 4.6 Средства защиты информации
• 5. Обоснование экономической эффективности проекта
• 5.1 Расчет показателей экономической эффективности проекта
• 5.2 Временные характеристики решаемых задач

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

1.1 Описание организации

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

Задачи, поставленные для выполнения заказчиком в лице ОАО Банк, решаются в несколько этапов.

Конечным результатом работы является создание программного продукта и размещение его на ЭВМ заказчика.

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

Экономическим объектом является ОАО Банк, специализирующееся на оказании банковских услуг клиентам.

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

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

На рисунке 1 представлена организационная структура

Рис. 1 Организационная структура ОАО «Банк».

1.2 Выбор технологии и метода проектирования

Современные информационные технологии предоставляют широкий набор способов реализации информационных систем. Выбор способа автоматизации рабочего места был основан на требованиях пользователя. Объектами проектирования является: автоматизированное рабочее место менеджера системы Клиент-Банк.

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

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

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

· По степени автоматизации — смешанный вариант проектирования. Для построения и анализа предметной области используется CASE-средство анализа BPWin 4.0. Результатом является создание функциональной модели деятельности. Проектирование БД проводится вручную без использования специальных инструментальных программных средств, так как предусматривается проектирование небольшой по структурной сложности системы.

· По степени использования типовых проектных решений — оригинальное (индивидуальное) проектирование. Это связано с тем, что все проектные решения будут разработаны с самого начала в соответствии с требованиями к АРМ.

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

Процесс каскадного проектирования в жизненном цикле ИС в соответствии с применяемым в нашей стране ГОСТ 34.601−90 «Автоматизированные системы. Стадии создания» делится на следующие семь стадий:

1. исследование и обоснование создания системы;

2. разработка технического задания;

3. создание эскизного проекта;

4. техническое проектирование;

5. рабочее проектирование;

6. ввод в действие;

7. функционирование, сопровождение, модернизация На практике эти стадии группируются в 4 стадии процесса канонического проектирования:

1. предпроектная;

2. проектирование;

3. внедрение;

4. эксплуатация и сопровождение.

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

Данными объектами в нашем случае являются:

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

· работа с клиентами;

· анализ деятельности банка;

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

· информационные потоки и процессы их обработки.

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

1.3 Задачи, подлежащие автоматизации

1) Хранение и изменение данных.

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

2) Поисковые процедуры:

· Поиск клиентов

· Поиск проведенных операций по счетам клиента

3) Контроль расчетов

Система должна :

· Контролировать формат вводимых данных

· Предупреждать о возможных ошибках

· Вести архив (журнал) расчетов

4) Формирование отчетов:

· Отчет о счетах клиента

· Отчет о внешних переводах по выбранному счету клиента

· Отчет о конвертации средств выбранного клиента

· Отчет о коммунальных платежах клиента

5) Формирование справок:

· Справочник курсов валют

· Справочник банков

· Информация о клиенте

· Справочник комиссий за осуществление операции по счету

1.4 Анализ рынка программных средств

На российском рынке присутствует целый ряд компаний — разработчиков автоматизированных банковских информационных систем (АБИС).

Наиболее известной компанией — разработчиком АБИС был признан «Диасофт» (31%), на втором месте — «R-Style» (26%), на третьем — ПрограмБанк (10%).

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

Основное преимущество решения 5NT (c) — комплексная автоматизация организации средствами одной системы, в рамках единого информационного пространства. Решение позволяет перевести на один программный продукт все подразделения банка, занимающиеся расчетно-кассовым обслуживанием, кредитными, депозитными операциями, операциями с ценными бумагами, операциями на денежных рынках, операциями с пластиковыми картами и другими видами операций.

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

Компания «R-Style Softlab» — наиболее расространенным является продукт RS-Bank -.5.O. Ядро программного комплекса RS-Bank/Perasive — RS-Bank -.5.0 — предназначено для автоматизации расчетно-кассового обслуживания и бухгалтерского учета. Оно позволяет также вести параллельный налоговый учет в соответствии с российским законодательством, формировать обязательную отчетность для Банка России и МНС, а также осуществлять операции по противодействию легализации доходов, полученных незаконным путем, согласно Федеральному закону № 115-ФЗ. Кроме того, RS-Bank выполняет весь цикл задач по расчетно-кассовому обслуживанию юридических лиц, включая взаимодействие с РКЦ, расчет и начисление процентов, плату за обслуживание, ведение картотек и пр. При этом в рамках входящих в комплекс автоматизированных систем RS-Retail, RS-Loans и RS-Incounting возможно ведение аналитического учета (например, по вкладчикам, кредитным договорам, материальным ценностям), в то время как синтетический учет ведется в RS-Bank -. 5.O.

Компания «ПрограмБанк» предлагает на рынке две системы: ин­тегрированные банковские системы «Гефест» и «Центавр Дельта».

«Центавр Дельта» — это современная система, основанная на технологии «клиент-сервер», которая обеспечивает высокую производительность при автоматизации банковской деятельности и исключает затраты, связанные с традиционными SQL-СУБД. Система «Центавр Дельта» является развитием ИБС «Центавр/ Центавр ADS» и совмещает в себе все функциональные возможности ИБС «Центавр» с мощностью и надежностью СУБД Ad-antage Database Ser-er.

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

1.5 Выбор технических и программных средств

1.5.1 План помещения

На следующем рисунке представлен план помещения ОАО Банк

Рис. 2 план помещения ОАО Банк

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

1.5.2 Спецификация технических и программных средств

ПО должно соответствовать следующим основным принципам:

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

· масштабируемость и высокая производительность

· совместимость

· наличие встроенной системы безопасности

· надежность

· возможность модернизации

ОС должна позволять организовать работу пользователя на рабочих

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

Прикладное ПО должно соответствовать следующим требованиям:

· унификация пользовательских интерфейсов

· совместимость ПО

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

· обеспечение сохранности и восстановления баз данных

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

Для организации работы системы необходимо:

Сервер — 1 шт.

Рабочая станция — 3 шт.

Коммутатор — 1 шт.

Кабель — витая пара, 150 м.

Принтер — 3 шт.

Сканер — 1шт.

Рекомендуемое оборудование:

1. Сервер — фирма Lenovo:

· Процессор — intel core i7 2,4 ГГц

· Оперативная память — 4гб и более

· HDD — 1тб

· ОС — Windows Server 2008

· Сетевой адаптер — 100 мбит/с

· СУБД — MS SQL Serever 2008

2. Рабочая станция:

· Процессор — intel core i3 2,6 ГГц

· Оперативная память — 3гб

· HDD — 320 гб

· ОС — Windows 7

· Сетевой адаптер — 100 мбит/с

3. Коммутатор — ASUS GX-D1081

4. Принтер — HP LaserJet 1022

5. Сканер — HP ScanJet G2410

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

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

1.5.3 СУБД

В качестве СУБД была выбрана — MS SQL 2000.

Одним из главных преимуществ MS SQL Server является его тесная интеграция с современными средствами разработки приложений такими как Visual Basic, Visual C++. SQL Server обеспечивает поддержку и ряда других интерфейсов доступа к данным, которые используются популярными средствами разработки.

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

автоматизация рабочий место менеджер

2. Моделирование ИС

Для описания основных бизнес-процессов предметной области было использовано средство моделирования бизнес-процессов BPWin. При моделировании была использована нотация IDEF0.

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

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

Рис. 3: А0. Диаграмма дерева узлов модели

Для описания существующей на предприятии системы управления была построена контекстная модель.

Рис. 4: А-0. Контекстная модель системы Клиент-Банк

Данные для авторизации — данные, которыми обладает работник банка необходимые для входа в систему.

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

Правила и Процедуры — регламентирующая работу с системой информация.

Менеджер системы — работник банка, осуществляющий деятельность в данной модели.

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

А-0. Система Клиент-Банк.

ПРОЦЕСС: Деятельность организации

ВХОД: Запросы от клиента

ВЫХОД: Проведенная операция

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

ПОДПРОЦЕССЫ:

А1. Авторизация

А2. Ввод данных операции

А3. Отправка на выполнение

Модель верхнего уровня «Деятельность организации»

Рис. 5: А0. Модель верхнего уровня «Деятельность организации».

А0. Деятельность организации

ПРОЦЕСС: Авторизация

ВХОД: Данные для авторизации

ВЫХОД: Вход в систему

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

ПОДПРОЦЕССЫ:

· Ввод данные авторизации

· Проверка данных авторизации

ПРОЦЕСС: Ввод данных операции

ВХОД: Вход в систему, Запросы от клиента

ВЫХОД: Запрос на исполнение

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

ПОДПРОЦЕССЫ:

· Ввод данных клиента

· Счета клиента

· Ввод реквизитов операции

· Отправка запроса

ПРОЦЕСС: Отправка на выполнение

ВХОД: Запрос на исполнение

ВЫХОД: Запрос подтвержден, Запрос отклонен

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

ПОДПРОЦЕССЫ:

· Проверка данных запроса

· Отложенные запросы

ПРОЦЕСС: Выполнение операции

ВХОД: Запрос подтвержден

ВЫХОД: Проведенная операция

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

Декомпозиция модели «Авторизация»

Рис. 6: А1. Декомпозиция модели «Авторизация».

А1. Авторизация

ПРОЦЕСС: Ввод данных авторизации

ВХОД: Данные для авторизации

ВЫХОД: Введенные данные

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Подсистема авторизации

ПРОЦЕСС: Проверка данных авторизации

ВХОД: Введенные данные

ВЫХОД: Вход в систему, Вход запрещен

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Подсистема авторизации

Декомпозиция модели «Ввод данных операции»

Рис. 7: А2.Декомпозиция модели «Ввод данных операции».

А2. Ввод данных операции

ПРОЦЕСС: Ввод данных клиента

ВХОД: Запросы от клиента

ВЫХОД: Клиент выбран

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

ПРОЦЕСС: Счета клиента

ВХОД: Клиент выбран, Запросы от клиента

ВЫХОД: Счет выбран

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

ПРОЦЕСС: Ввод реквизитов операции

ВХОД: Счет выбран, Запросы от клиента

ВЫХОД: Данные операции

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Менеджер системы

Декомпозиция модели «Отправка на выполнение»

Рис. 8 А3.Декомпозиция модели «Отправка на выполнение».

А3. Отправка на выполнение

ПРОЦЕСС: Проверка данных запроса

ВХОД: Запрос на исполнение

ВЫХОД: Запрос отклонен, Проверенные данные

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Подсистема проверки данных

ПРОЦЕСС: Отложенные запросы

ВХОД: Проверенные данные

ВЫХОД: Запрос отклонен, Запрос подтвержден

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Подсистема проверки данных

А4. Выполнение операции

ПРОЦЕСС: Проверка данных запроса

ВХОД: Запрос подтвержден

ВЫХОД: Проведенная операция

УПРАВЛЕНИЕ: Правила и процедуры

ИСПОЛНИТЕЛЬ: Подсистема выполнения операции

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

3.1 Организационно-техническая сущность комплекса задач

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

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

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

3.2 Описание входной и выходной информации

Таблица 1. Идентификаторы документа «Отчет о счетах клиента»

Внешний вид документа

Таблица 2. Идентификаторы документа «Отчет о внешних переводах по выбранному счету клиента»

Внешний вид документа

Таблица 3. Идентификаторы документа «Отчет о конвертации средств выбранного клиента»

Внешний вид документа

Таблица 4. Идентификаторы документа «Отчет о коммунальных платежах клиента»

Внешний вид документа

Справки

Таблица 5. Идентификаторы документа «Справочник курсов валют»

Внешний вид документа

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

Внешний вид документа

Таблица 7. Идентификаторы документа «Информация о клиенте»

Внешний вид документа

Таблица 8. Идентификаторы документа «Справочник комиссий за осуществление операции по счету»

Внешний вид документа

3.3 Описание входной информации

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

Так для операции внешний перевод необходимыми входными данными являются:

· Номер счета списания

· Номер счета зачисления

· Назначение платежа

· Сумма платежа Для операции конвертации средств :

· Номер счета списания

· Номер счета зачисления

· Сумма перевода Для операции оплаты коммунальных услуг:

· Номер счета

· Код абонента

· Месяц

· Год

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

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

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

4.1 Проектирование инфологической модели сущность-связь (концептуальное проектирование)

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

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

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

4.2 Выбор СУБД

Для создания базы данных будем использовать MS SQL Server 2000, который основан на реляционной модели данных.

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

В классическом понимании, СУБД — это комплекс языковых и программных средств, предназначенных для ведения, создания и совместного использования БД многими пользователями.

Для создания БД будем использовать MS SQL Server 2000, который основан на реляционной модели данных, описывающей структуры данных в виде наборов отношений.

Microsoft SQL Server 2000 — это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В сервер SQL Server 2000 включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения. Кроме того, SQL Server 2000 полностью использует все возможности операционной системы Windows, включая поддержку до 32 процессоров и 64 ГБ ОЗУ.

После выбора приступим к проектированию даталогической модели, ориентированную на конкретную СУБД, т. е. на MS SQL Server.

4.3 Даталогическое проектирование, определение типов и размеров атрибутов

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

Целью данного вида проектирования является описание схемы реляционной БД в терминах выбранной СУБД.

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

Преобразование отношений осуществляется одним из трех способов в зависимости от мощности и кардинальности связи.

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

— Счет (Номер счета, Тип счета, Валюта, Наименование клиента, Адрес, Наименование банка, Сумма на счете, Дата открытия счета)

— Конвертация средств (Код конвер, Номер счета списания, Номер счета зачисления, Сумма перевода, Дата операции)

— Внешний перевод (Код перевода, Номер счета списания, Номер счета зачисления, Назначение платежа, Сумма платежа, Дата операции)

— Оплата ком услуг (Код ком, Номер счета, Код абонента, Месяц, Год, Сумма платежа, Дата операции)

— Справочник валют (Код валюты, Код букв, Наименование валюты, Курс)

— Справочник банков (БИК, Наименование банка, Корсчет, Адрес)

— Справочник комиссий (Код комисс, Название операции, Комиссия, Информация)

4.4 Создание и разработка базы данных

В MSSQL Server 2000 была создана новая база данных. Затем было создано 7 таблицы, заданы первичные и внешние ключи.

1) Счет

Рис. 9 Таблица счет

2) Внешний_перевод

Рис. 10 Таблица внешний перевод

3) Конвертация_средств

Рис. 11 Таблица конвертация_средств

4) Оплата_ком_услуг Рис. 12 Таблица оплата_ком_услуг

5) Справочник_валют Рис. 13 Таблица справочник_валют

6) Справочник_банков Рис. 14 Таблица справочник_банков

7) Справочник_комиссий

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

Рис. 16 Диаграмма БД

4.5 Поддержка целостности данных

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

Различают физическую и логическую целостность:

Физическая целостность:

· Наличие физического доступа к данным. Для сохранения данных в случае сбоя системы современные СУБД поддерживают механизмы создания резервных копий и восстановления данных.

· Отсутствие логических ошибок в БД, к которым относятся:

o Нарушение структуры БД или её объектов

o Удаление или изменение установленных связей между таблицами

o Правильность ввода данных

Логическая целостность:

· Контроль и проверка целостности с помощью ограничений:

o Структурные ограничения:

o Целостность сущности (реляционные СУБД должны допускть работу только с однородными структурами данных типа реляционная таблица)

o Целостность на уровне ссылок

· Функциональные зависимости

1. Ссылочная целостность сохраняет определенные связи между таблицами при добавлении или удалении строк. В SQL Server ссылочная целостность основана на связи первичных и внешних ключей (либо внешних и уникальных ключей) и обеспечивается с помощью ограничений FOREIGN KEY и CHECK.

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

3. При отказе диска или отключения электропитания возможно повреждение страниц данных. SQL Server 2000 Enterprise Edition обеспечивает целостность данных: при повреждении страниц данных узел-партнер автоматически пытается восстановить данные. Это позволяет быстрее устранять последствия физического повреждения данных, зачастую без вмешательства администратора.

4.6 Средства защиты информации

В системе реализован контроль входа по вводу логина и пароля, путем создания в SQL Server учетной записи.

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

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

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

реализация алгоритма цифровой подписи и её проверки, должна соответствовать ГОСТ 34.2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи».

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

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

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

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

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

Э = Эк + Эп,

где Э — экономическая эффективность проекта; (1)

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

5.2 Временные характеристики решаемых задач

Табл. 9 Условно-постоянные параметры исходных данных.

Расчет коэффициента, учитывающего накладные расходы.

Накладные расходы:

— аренда помещений 200 000 руб. в месяц;

— канцелярские расходы 20 000 руб. в месяц;

— коммунальные платежи 80 000 руб. в месяц;

— налоги 200 000 руб. в месяц;

— расходы на охрану 50 000 руб. в месяц;

— заработная плата аппарата управления 35 000 * 5 человек = 175 000 руб. в месяц;

Заработная плата персонала? 15 000 * 20 сотрудников = 300 000 руб. в месяц.

Процент накладных расходов рассчитывается как:

Накладные расходы = 725 000 руб. в месяц.

145%

3. Временные характеристики решаемых задач

Табл.10 Временные характеристики решаемых задач

1) Kр — количество решений в год

Оперативный учет:

— оформление внешних переводов — 1200 решений

— оформление конвертации средств — 1400 решений

— оформление оплаты коммунальных услуг — 1800 решений

— удаление записей — 400 решений

Итого: 4800 решений в год

Оперативный анализ:

— Справочник валют — ежедневно 3 справки = 3*304 = 912 решений

— Справочник банков — еженедельно 1 справку = 1*4*12 = 48 решений

— Справочник комиссий — еженедельно 1 справку = 1*4*12 = 48 решений

Итого: 1080 решений в год

Формирование отчетов:

Отчеты формируются по каждой проведенной операции.

Итого: 4800 решений в год

2) Тр1 — время ручной обработки до автоматизации, час

Оперативный учет:

— оформление внешних переводов — 0,14

— оформление конвертаций средств — 0,12

— оформление оплаты коммунальных услуг — 0,1

— удаление записей — 0,09

Оперативный анализ:

Для набора любой справки в MS Word нужно около 8 минут или 0,13 часа.

Формирование отчетов:

На формирование отчетов до автоматизации необходимо было примерно 15 минут или 0,25 часа.

3) Тм1 — время машинной обработки до автоматизации, час.

Обновление файла Excel составляло около 12 минут или 0,2 часа.

4) Тр2 — время ручной обработки после автоматизации, час.

Оперативный учет:

— оформление внешних переводов — 0,08

— оформление конвертаций средств — 0,06

— оформление оплаты коммунальных услуг — 0,05

— удаление записей — 0,02

Оперативный анализ:

Стандартные справки уже есть в системе.

Формирование отчетов:

Отчеты уже есть в системе.

5) Тм2 — время машинной обработки после автоматизации, час

Оперативный учет:

Обновление БД займет примерно 15 минут.

Оперативный анализ:

Для создания справки понадобится всего несколько секунд? 0,55 часа (примерно 2 секунды).

Формирование отчетов:

Для формирования отчетов необходимо примерно 0,0083 часа (примерно 30 секунд).

5. Подсчет расчетных показателей

1. Расчет затрат ручного труда, руб.:

До автоматизации: Зр1 = 425 244,16 руб.

После автоматизации: Зр2 = 122 456,32 руб.

2. Зарплата инженерно-технических работников, обслуживающих вычислительную технику, руб.:

Зитр1 = 264 378,77 руб.

Зитр2 = 76 132,39 руб.

3. Затраты на электроэнергию, руб.:

Зэл1 = 3 232,27 руб.

Зэл2 = 930,79 руб.

4. Затраты капитальные и приравненные к ним затраты на задачу, руб.:

До автоматизации:

Сетевое оборудование:

— 1 сервер =70 000 руб.,

— 3 рабочие станция (каждая по 25 000 руб.)=75 000 руб.,

— 1 коммутаторов = 2 000 руб.,

— 3 принтера (каждый по 3 000 руб.) = 9 000 руб.

— кабель 150 м (1 м по 10 руб.) = 1 500 руб.

Всего на рецепции 3 компьютеров. Следовательно, на один компьютер приходится: (70 000+2 000+1 500+75 000+9000) / 3 = 52 500 руб.

Зк1 = 1 Ч 25 000 + 52 500=77 500 руб.

После автоматизации:

Для создания системы необходимо дополнительно:

— Delphi 7. Цена 70 287.72 руб.

На один компьютер будет приходиться: 70 288 / 3 = 23 430

Дополнительные затраты составят: 23 430 руб.

Зк2 = 77 500 + 23 430 = 100 930 руб.

5. Затраты на ремонт, руб.:

Зрем1 = 6 393,75 руб.

Зрем2 = 8 326,73 руб.

6. Расчет амортизационных отчислений:

До автоматизации:

А1= 12 458,00 руб.

После автоматизации:

При стоимости программы более 20 000 рублей, она учитывается в составе нематериальных активов. Амортизация по таким активам начисляется ежемесячно. На программу Delphi 7 амортизация не начисляется, т.к. её стоимость меньше 20 000 руб.

А2 = 14 455,50 руб.

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

Зэкс1 = 286 462,79 руб.

Зэкс2 = 99 845,40 руб.

8. Затраты на проектирование, руб.:

Зпр1 = 0.

Зпр2 = 307 160,81 руб.

6. Расчет показателей экономической эффективности

1. Расчет затрат на дополнительные капитальные вложения, руб.:

Квл = 330 590,81 руб.

2. Годовая экономия, руб.:

Э = 116 170,44 руб.

3. Годовой экономический эффект, руб.:

Ен = 0,15 руб.

Эг = 66 581,82 руб.

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

Ер = 0,35

5. Расчетный срок окупаемости, год:

Т = 2,85 года

Показатели экономической эффективности

Годовая экономия в связи с внедрением ИС составит 116 170 руб.