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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

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


Наименование:


дипломная работа нтернет банкнг

Информация:

Тип работы: дипломная работа. Добавлен: 08.09.2012. Сдан: 2011. Страниц: 18. Уникальность по antiplagiat.ru: < 30%

Описание (план):


ЗМІСТ 
 
Вступ  
Розділ 1. Опис предметної області 
1.1 Послуги Інтернет. 
1.2 Самообслуговування як розширення клієнтських можливостей 
1.3 Архітектура Інтернет-банкінгу 
1.4 Обслуговування клієнтів банку через Інтернет 
Розділ 2. Проектування автоматизованої системи обслуговування клієнтів банку через Інтернет. 
2.1 Мета роботи 
2.2.1Функціональні вимоги до системи. 
2.3 Вибір та обгрунтування технології проектування та інструментальних засобів розробки. 
2.4 Постановка завдань по підсистемам. 
2.4.1 Діаграми варіантів використання. 
2.4.2.4.Діаграмі класів. 
2.5 Вибір СУБД для реалізації БД. 
2.5.1 Вибір СУБД. 
2.5.2.5.Проектування бази даних. 
Висновки до розділу. 
Розділ 3. Реалізація та тестування. 
3.1 Ієрархія форм. 
3.2 Організація інтерфейсу з користувачем. 
3.3.2 Постановка завдання для тестування. 
3.4 Тестування. 
3.5 Аналіз результатів, отриманих при тестуванні. 
Висновки до розділу. 
Розділ 4. Розрахунок економічної ефективності проекту. 
4.1 Розрахунок одноразових витрат на розробку ПЗ. 
4.2 Одноразові витрати організації замовника ПЗ при впровадженні автоматизованих робочих місць (АРМ). 
4.3 Джерела фінансування проекту. 
4.4.3 Поточні витрати користувача ПЗ при експлуатації АРМ.
 
Висновки до розділу 
Висновок 
Список літератури

 

      Вступ

 
     Комп'ютерні технології, що стрімко розвиваються, змінили спосіб життя мільйонів людей, а світова комп'ютерна мережа 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-Апплете реалізований весь інтерфейс користувача: екранні й друковані форми документів, перевірки правильності заповнення, протокол захищеної взаємодії із сервером БД, шифрування даних, генерація крипто ключів, механізм ЕЦП клієнта під фінансовими документами й обмін фінансовими документами з автоматизованими банківськими системами.
     Незалежно від використовуваної схеми, визначають склад Інтернет-Банкінга:
    Клієнтська частина системи. Це інтернет-сервер, установлюваний у банку, що відвідують клієнти банку для виконання операцій у системі де й реалізований протокол захищеної взаємодії й шифрування даних.
    Сервер БД. Зберігає всі документи й відкриті ключі ЕЦП клієнтів, всю інформацію про клієнтів і довідники. У даній частині системи відбувається первинна реєстрація клієнтів, визначення рахунків і повноважень. Зберігаються довідники, використовувані клієнтом у роботі й повній інформації про клієнта.
    Шлюз до АБС. Забезпечує обмін даними між системами. Звичайно підтримується робота АБС у пакетному режимі, режимі реального часу, може бути комбіновано. Найпоширенішим є обмін текстовими файлами заздалегідь певного формату.
     Для нашого ринку традиційним рішенням є: на стороні клієнта встановлюється спеціальне ПЗ, додатково 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 сумісних комп'ютерах.
     Мінімальна  конфігурація:
    Тип процесора Pentium III або Athlon і вище;
    Частота процесора 333Mhz і вище;
    Обсяг оперативного запам'ятовувального пристрою 64 Мб і більше;
    Обсяг вільного простору на жорсткому диску 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).
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.