Введение

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

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

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

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

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

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

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

В первой главе описано исследование предметной области. Раскрываются теоретические моменты работы.

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

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

Четвертая глава описывает экономическую сторону проекта. Дано обоснование проекта с точки зрения экономической эффективности.

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

Глава 1. Описание предметной области

1.1 Услуги Интернет

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

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

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

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

Преимущества:

Сокращение производственных затрат;

Удобство обслуживания клиентов;

Скорость оформления заказов.

1.2 Самообслуживание как расширение клиентских возможностей

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

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

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

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

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

1.3 Архитектура интернет-банкинга

Существуют 3 основных решения по реализации транзакции между клиентом и базой данных банка с применением Интернет-технологии:

· «голый» WEB. Эта схема попадает под определение «тонкого» клиента. Интерфейс реализован на базе HTML, в качестве протокола HTTP поверх SSI. Клиент использует обычный WEB-браузер. В банке установлен WEB-сервер для исполнения WEB-приложения, который с одной стороны динамически формирует HTML-страницы для клиента, а с другой обращается с сервером базы данных.

· WEB + программное обеспечение. В данном решении клиенту предлагаются специальные программы или plugin-модули для конкретной версии WEB-браузера. Сложности: проведение установки и настройки специализированного ПО у клиента и необходимость периодического обновления этого ПО. Как следствие, необходимость создания в банке группы сотрудников для технической поддержки клиентов и дополнительные издержки банка. Так как ПО устанавливается у клиента - это система с «толстым» клиентом, а обработка на нашей машине.

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

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

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

· Сервер БД. Хранит все документы и открытые ключи ЭЦП клиентов, всю информацию о клиентах и 9справочники. В данной части системы происходит первичная регистрация клиентов, определение счетов и полномочий. Хранятся справочники, используемые клиентом в работе и полная информация о клиенте.

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

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

1.4 Обслуживание клиентов банка через Интернет

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

Глава 2. Проектирование АСУ

2.1 Цель работы.

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

Для достижения этой цели были решены следующие задачи:

1. Рассмотрены операции клиента и банка;

2. Проведен анализ;

3. Определены основные требования к разрабатываемой системе;

4. Спроектирована и разработана система обслуживания клиентов банка через ИНТЕРНЕТ;

5. Создан тестовый пример;

6. Произведено тестирование системы;

7. Проведена оценка экономической эффективности разработанной системы.

2.2 Функциональные требования к системе

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

· оформление заказа на данную услугу(Клиент-Банк) - выполняется администратором по работе с клиентами, когда клиент определился;

· формирование Базы Данных клиентов;

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

· осуществление поиска по указанным параметрам - для администратора:

· по фамилии клиента;

· по номеру операции;

· по фамилии администратора

· возможность работы с операциями - поиск по описанию операций;

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

2.2.2 Исходные данные:

· Анкетные данные;

· Желание клиента.

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

Результаты поиска;

· Договор с клиентом;

· Отчеты;

2.2.4 Требования к надёжности.

· Предусмотреть контроль вводимой информации.

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

· Обеспечить целостность хранимой информации.

· Обеспечить защиту от несанкционированного доступа к информации.

2.2.5 Требования к составу и параметрам технических средств.

Система должна работать на IBM совместимых компьютерах.

Минимальная конфигурация:

1. Тип процессора Pentium III или Athlon и выше;

2. Частота процессора 333Mhz и выше;

3. Объём оперативного запоминающего устройства 64 Мб и более;

4. Объем свободного пространства на жестком диске 5 Mб и выше.

Требования к информационной и программной совместимости.

Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows Me, Windows 2000, Windows NT, Windows XP). Выход в сеть Internet.

2.3 Выбор и обоснование технологии проектирования и инструментальных средств разработки

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

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

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

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

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

· сложности проектируемой системы;

· необходимой полноты ее описания;

· знаний и навыков участников проекта;

· времени, отведенного на проектирование.

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

BPWin.

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

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

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

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

Рассмотрим контекстную диаграмму (Рис1):

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

· Закон «Об информатике и информатизации»;

· Законы, регулирующие предпринимательскую деятельность.

Входная информация, изображенная в виде стрелочек, входящих с левой стороны блока:

· Анкетные данные;

· Желание клиента.

Выходная информация, представленная с правой стороны:

· Договор с клиентом;

· Результаты поиска;

· Отчеты.

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

· Представитель банка;

· Администратор.

Рис. 1 Контекстная диаграмма

Далее представлена диаграмма декомпозиции контекстной диаграммы (Рис2). Рассмотрим ее более подробно:

Рис. 2 Диаграмма декомпозиции процесса

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

Рассмотрим каждый подпроцесс более подробно:

Оформление заказа на услугу:

Входная информация:

· Желание клиента;

· Анкетные данные.

Выходная информация:

· Ответ на заказ;

· Договор с клиентом.

Формирование БД клиентов:

Входная информация:

· Анкетные данные;

· Ответ на заказ клиента.

Выходная информация:

· Список клиентов.

Осуществление поиска:

Входная информация:

· Список клиентов.

Выходная информация:

· Результаты поиска.

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

Входная информация:

· Список клиентов;

· Анкетные данные.

Выходная информация:

· Различные виды отчетов.

Rational Rose.

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

· диаграммы классов;

· диаграммы состояний;

· диаграммы сценариев;

· диаграммы модулей;

· диаграммы процессов;

· спецификации классов, объектов, атрибутов и операций

· заготовки текстов программ;

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

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

2.4 Постановка задач по подсистемам

2.4.1 Диаграмма вариантов использования (клиент)(Рис3).

Суть этой диаграммы сводится к тому, что клиент выполняет операцию. Это его основная функция. Но, перед тем как её выполнить, он изучает сайт. Если что-то не находит в списке операций, он может воспользоваться поиском. В любом случае, независимо от его «пути», он выбирает операцию, проводит её и получает, в итоге, отчет. Это что касалось КЛИЕНТа, а дальше рассмотрим точку зрения администратора (Рис 4).

Диаграмма вариантов пользования (Администратор)(Рис4).

В функции администратора входит:

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

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

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

· Осуществление поиска клиента по фамилии, либо по статусу.

· Осуществить регистрацию клиента. Анкетные данные клиента внести в базу данных.

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

2.4.2 Диаграммы классов

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

Данная диаграмма классов позволяет увидеть взаимоотношения между объектами системы, связи и зависимости (Рис5).

Рис5. Диаграмма классов

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

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

Класс-потомок «Представитель банка» выполняет следующие операции:

· Оформление заказа на услугу;

· Предоставление договора клиенту.

Класс-потомок «Администратор» выполняет следующие операции:

· Сформировать базу данных;

· Обновить базу данных;

· Выполнить поиск;

· Обновить сайт.

Ну а в иерархии «Отчеты» нет никаких классов-потомков.

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

2.5 Выбор СУБД для реализации БД

2.5.1 Выбор СУБД

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

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

СУБД разрабатываются с целью обеспечения эффективной обработки больших объёмов информации, намного больших, чем те, с которыми справляются электронные таблицы;

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

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

Так как средой программирования была выбрана PHP, то логично, что работая в связке Apache/PHP/MySQL, системой управления базой данных был выбран MySQL.

СУБД MySQL - одна из множества баз данных, поддерживаемых в PHP. MySQL разработал Михаэль Видениус. MySQL является относительно небольшой и быстрой реляционной СУБД основанной на традициях Hughes Technologies Mini SQL (mSQL).

Система MySQL распространяется бесплатно и обладает достаточной мощностью для решения реальных задач. SQL - это аббревиатура от слов Structured Query Language, что означает структурированный язык запросов. Этот язык является стандартным средством для доступа к различным базам данных.

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

Основные стороны пакета MySQL:

· Многопоточность. Поддержка нескольких одновременных запросов;

· Оптимизация связей с присоединением многих данных за один проход;

· Записи фиксированной и переменной длины;

· ODBC драйвер в комплекте с исходником;

· Гибкая система привилегий и паролей;

· До 16 ключей в таблице. Каждый ключ может иметь до 15 полей;

· Поддержка ключевых полей и специальных полей в операторе CREATE;

· Поддержка чисел длинной от 1 до 4 байт (ints, float, double, fixed), строк переменной длины и меток времени;

· Интерфейс с языками C и perl;

· Основанная на потоках, быстрая система памяти;

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

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

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

Рис.6 Схема данных.

Таблица «Менеджеры»

Поля:

ID менеджера - ключевое поле; Фамилия - текстовый; Имя - текстовый; Отчество - текстовый; Должность - текстовый.

Таблица «Клиенты»:

Поля:

ID_клиента- ключевое поле; Фамилия - текстовый; Имя - текстовый; Отчество - текстовый; Номер_паспорта - числовой; Телефон - числовой.

Таблица «Договоры»:

Поля:

ID_договора - ключевое поле; Клиент - текстовый; Менежер - текстовый; Число_создания - числовой.

Таблица «Счета»:

Поля:

ID_счета - ключевое поле; Сумма_на_счете - числовой; Договор - текстовый.

Таблица «Операции»:

Поля:

ID_операции- ключевое поле; ID_счета - числовой; Сумма - числовой; Операция - текстовый.

Таблица «Пароли»:

Поля:

ID_пароля- ключевое поле; Счет - числовой; Логин - текстовый\числовой; Пароль - текстовый\числовой.

Выводы по главе

Данная глава посвящена выбору методологии разработки и среды проектирования. Были использованы BPWin и Rational Rose.

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

Глава 3. Реализация и тестирование

3.1 Иерархия форм (Рис3.1)

3.2 Организация интерфейса с пользователем

Когда клиент заходит на сайт, то первым образом он попадает на главную страницу (рис3.2)

Рис 3.2

Где, как вы видите, есть МЕНЮ (слева) и отзывы ведущих директоров банков (справа). В меню находится всё, чтобы, как можно понятнее, представить информацию и сайте, т.е. описание системы, возможности, Документы, подключение к системе, контакты и два режима, пользовательский и режим администрирования.

Далее переходим уже к работе. Слева есть ссылочка «Пользовательский режим», по нажатии на которую мы попадаем в меню входа (Рис3.5.):

Рис3.5

Если логин и пароль введены не правильно, то появляется сообщение об этом. Ну а если вход прошел успешно, то мы попадаем непосредственно в раздел операций (Рис3.6.).

Рис3.6

Где, в свою очередь, по нажатию на выбранную операцию попадаем в режим отчета (Рис3.7.):

Рис3.7

Если нажать на ссылку «Назад», то мы попадаем опять в раздел операций. И так до тех пор, пока клиент не выполнит всё запланированное.

Для администратора же существует свой вход, также по логину и паролю (Рис3.8.).

Главная форма выглядит следующим образом:

Рис3.8

На этой форме есть 3 вкладки: Клиенты, Операции и Отчеты. «Внутри» каждой из них находятся свои таблицы и данные. Со всеми из них можно производить операции удаления, добавления, редактирования.

3.3 Постановка задачи для тестирования

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

Для пользователя.

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

Для администратора.

Зайти на сайт в режиме администрирования, проверив при этом возможность неверного логина или пароля. Проверить каждую закладку. В Категории удаления операция и клиентов проверить возможность удаления заказов и клиентов.

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

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

· На главной странице выбран пользовательский режим;

· При попытке войти в систему был неправильно введен пароль. В ответ на это было выдано сообщение: Неверные логин и/или пароль;

· После этого последовал новый ввод, который не содержал ошибочных данных и клиент попал в раздел операций;

· По нажатию на операцию последовало окно с отчетом;

· Таким образом, операция прошла успешно.

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

· На главной странице выбран режим администрирования;

· При попытке войти в систему администрирования был неправильно введен пароль. В ответ на это было выдано сообщение: Неверные логин и/или пароль;

· После этого последовал новый ввод, который не содержал ошибочных данных и администратор попал на страницу;

· Было проведено тестирование на удаление клиентов;

· Тестирование было удачным;

· На следующей закладке операции, также видны все данные о клиентах и операциях;

· Была проверена возможность удаления и добавления операции;

· Тестирование было удачным;

· На следующей закладке отчеты, видны все данные о клиентах и операциях;

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

· Тестирование было удачным;

· Таким образом, в режиме администрирования были проверены все функции администратора.

3.5 Анализ результатов, полученных при тестировании

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

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

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

Таким образом, можно говорить об устойчивом и корректном функционировании системы.

Выводы по главе

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

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

Глава 4. Расчёт экономической эффективности проекта

4.1 Расчет единовременных затрат на разработку ПО

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

Фактическая трудоемкость по стадиям проектирования представлена в виде таблицы (табл.4.1).

Таблица 4.1.

Содержание стадий научно-исследовательской работы (НИР).

Общая фактическая трудоемкость разработки ПО составляет:

где - общая трудоемкость разработки, дни; Тi - трудоемкость по стадиям, дни; n - количество стадий разработки.

В смету затрат на разработку ПО включаются:

· материальные затраты;

Страницы: 1, 2