МIНIСТЕРСТВО ОСВIТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

Кафедра інформаційних систем

ЗВІТ

з переддипломної практики ТОВ «Харгіпротранс»

Виконав:

студент ф-ту ЕІ

5 курсу 5 групи

Дігтяр В.С.

Керівник від підприємства начальник Прокопенко В. Л.

Керівник від університету доцент кафедри ІС Скорін Ю.І.

2012

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

Кафедра інформаційних систем

Спеціальність 7.080401

курс 5, група 5, семестр 10

Завдання

на практику

студента

Дігтяра Вадима Сергійовича

1. Тема практики: “Розроблення модуля «аналіз та управління замовленнями клієнтів» інформаційної системи ТОВ «Харгіпротранс»».

2. Строк здачі студентом практики: 05.05.2012 р.

3. Вхідні дані до проекту: ДСТУ з обробки інформації, матеріали проектно-технологічної практики, готові програмні продукти, технічна документація на АІС, літературні джерела, інтернет-видання.

4. Зміст пояснювальної записки: Вступ. Розділ 1. Змістовний опис і аналіз предметної області, структурних і функціональних особливостей об’єкта управління. Розділ 2. Огляд і аналіз існуючих варіантів розв’язання задач модуля “Забезпечення автентичності даних на основі алгоритму mini-Umac”. Розділ 3. Розроблення специфікацій бізнес-вимог до модуля “ Розроблення модуля «аналіз та управління замовленнями клієнтів» інформаційної системи ТОВ «Харгіпротранс ”. Розділ 4. Технічне завдання на розробку проекту. Висновки.

5. Перелік графічного матеріалу: діаграми IDEF0; схема інформаційних зв’язків; UML-діаграми.

Дата видачі завдання: 23.01.2012 р.

Керівник проекту к.т.н., доцент кафедри ІС Скорін Ю.І.

Студент Дігтяр В.С.

ВСТУП

У сучасному бізнесі менеджмент, пов'язаний з керуванням замовленнями, стає критичним з точки зору споживчого сервісу. Численними дослідженнями встановлено, що час на виконання таких процедур як прийом, підготовка, передача, обробка, моніторинг замовлень становить від 50 до 70% загального циклу його виконання для більшості підприємств. Тому для підвищення якості обслуговування споживачів і якнайшвидшого задоволення їхніх очікувань необхідно скорочувати час і кількість складових циклу за рахунок більш ефективного менеджменту.

Загальна процедура управління замовленнями включає в себе кілька етапів, що утворюють так званий цикл замовлення:

прийом і попередня обробка інформації про замовлення;

передача;

конфігурування;

визначення джерел виконання замовлення;

планування;

моніторинг виконання і доставки замовлення споживачу.

Маркетинг - один з найбільш розвинених секторів інформаційних технологій, оскільки автоматизація інформаційних процесів в цій галузі в умовах інтенсивного розвитку ринкових відносин є стратегічним чинником конкуренції. Лише сучасні інформаційні технології дозволяють практично миттєво підключатися до будь-яких електронним масивів даних, отримувати всю необхідну інформацію і використовувати її для аналізу, прогнозування, прийняття управлінських рішень у сфері бізнесу, комерції, маркетингу.

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

Управління замовленнями це управління бізнес – процесами компанії и відповідно грамотний інжиніринг робочих потоків збільшує ефективність компанії в кількісних ( фінансових ) и якісних (строки роботи ) показниках.

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

Метою дипломного проекту є розроблення програми з єдиною БД, з доступним інтерфейсом для працівників компанії, що дозволить більш швидше та мобільніше приймати замовлення клієнтів, з можливістю розрахунку виконання даного замовлення, цим самим дозволить встановити більш тісні зв’язки з клієнтами.

РОЗДІЛ 1

Змістовний опис і аналіз предметної області, структурних і функціональних особливостей об’єкта управління

Характеристика ВАТ Харківський проектно-дослідницький інститут об’єктів транспорту «Харгіпротранс».

Послуги: проектування, інженерні роботи.

Інститут здійснює комплексну розробку проектно – кошторисної документації по наступним напрямкам:

нові залізно-дорожні лінії, другі шляхи, під’їздні шляхи;

автомобільні шляхи різноманітного призначення;

мости і шляхопроводи, підземні переходи, шляхопровідні розв’язки;

деповські споруди, комплекси по ремонту рухомого складу;

промивочно-пропарочні станції;

об’єкти виробничого призначення, соціально культурного побуту, житлового и громадського будівництва;

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

проектування полігонів захоронення твердих побутових відходів.

Фірму очолює директор. Йому підкорюються секретар-референт та наступні відділи:

департамент закупівель;

ддепартамент маркетингу;

юридичний департамент;

департамент збуту:

департамент персоналу;

ІТ- департамент;

склад;

бухгалтерія.

Загальна організаційна схема підприємства виконана в пакеті ARIS 6.2 і показана на рис. 1.1.

Рис 1.1. Загальна організаційна схема підприємства «Харгіпротранс»

Основнім завданням Харківського проектно-дослідницького інституту об’єктів транспорту «Харгіпротранс» є надання послуг по проектуванні різного роду об’єктів, які формуються шляхом створення заявки на проектування, в якій указуються: вид об’єкту, строки здачі проекту, формування рахунку на оплату та формування звіту. Успішність роботи компанії можна визначити по кількості виконаних замовлень.

Рис. 1.2. Контекстна діаграма бізнес-процесу «Аналіз і управління замовленнями клієнтів»

Рис. 1.3. Декомпозиція контекстної діаграми бізнес-процесу «Аналіз і управління замовленнями клієнтів»

Рис. 1.4. Декомпозиція задачі «Оброблення замовлення на проекти»

РОЗДІЛ 2

ОГЛЯД І АНАЛІЗ ІСНУЮЧИХ ВАРІАНТІВ РОЗВ’ЯЗАННЯ ЗАДАЧ МОДУЛЯ «АНАЛІЗ І УПРАВЛІННЯ ЗАМОВЛЕННЯМИ КЛІЄНТІВ»

Для вирішення задачі існує декілька програмних рішень. Їх порівняння представлено в табл.1.2.

Таблиця 1.2

Порівняльна характеристика програм аналогів

Критерії	TurboFly ERP	Виртуоз
1	2	3
Фірма розробник	Гольдберг-софт	IT company “Marka”
Фінансові можливості АІС	Автоматичне формування планів робіт; інтеграція фінансових документів і завдань; постановка будь-якого документа на контроль; система сповіщення по електронній пошті і в програмі; управління договорами; управління запасами	Управління запасами; управління замовленнями; планування продаж; управління продажами/резервування; управління договорами; звіти; інтеграція з іншими базами даних; віддалений доступ
Фірма розробник	Гольдберг-софт	IT company “Marka”
Принципи адаптації до особливостей конкретних підприємств	Гнучка відкрита технологія дозволяє змінювати і адаптувати систему	можливість налаштування на мережеву або персональну роботу (використанні програми в мережевому варіанті); можливість оперативної розробки і подальшого збереження звітів

Закінчення табл. 1.2

Критерії	TurboFly ERP	Виртуоз
1	2	3
Застосовуються АІС на Україну	Застосовується	Застосовується
Технології, що використовуються	Клієнт-серверна	Клієнт-серверна
Масштабованість	легко розширювана; великі можливості по розширенню програми і надбудов	легко розширювана
Використання ІС на різних програмно-апаратних платформах	Microsoft Windows XP, Vista, 7, Server	Microsoft Windows XP, Vista, 7, Server, Microsoft Windows 2000 Server та інші версії
Можливість інтеграції с іншими офісними програмами	Взаємозв’язок з програмою 1С: Бухгалтерія	Сполучення з бухгалтерськими програмами: "1С: Бухгалтерія 7.7", "Парус"
Ціна АІС	430$	475$

Для цих програмних продуктів далі наведено короткий опис, який характеризує основні варіанти використання продукту.

TurboFly ERP

Програмний комплекс TurboFly ERP призначений для автоматизації діяльності працівників компанії. Він включає такі основні функції:

автоматичне формування планів робіт;

інтеграція фінансових документів і завдань;

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

оцінка завантаження співробітників і поточних робіт і планів;

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

система сповіщення по електронній пошті і в програмі;

представлення діяльності компанії як один великий проект.

Рис.1.3. Форма для формування картки замовлення в TurboFly ERP

Програмний комплекс «Виртуоз» призначений для автоматизації діяльності працівників підприємства, для контролю матеріальних потоків і планування потреб в матеріальних ресурсах. Він включає такі функції:

облік недопоставок замовлених постачальникам товарів з налаштованим алгоритмом зняття недопоставок;

засоби автоматичного формування замовлень постачальникові на основі планів постачань і показників складу: поточного наявності, мінімального запасу, резерву, недопоставок, розміру партії;

договори на закупівлю;

відображення всіх складських операцій у фінансовому обліку;

всіляка аналітична статистика і звітність.

Рис.1.4. Форма для формування замовлення в системі «Виртуоз»

РОЗДІЛ 3

РОЗРОБЛЕННЯ СПЕЦИФІКАЦІй БІЗНЕС-ВИМОГ ДО МОДУЛЯ “Забезпечення автентичності даних на основі алгоритму mini-Umac”

3.1. Глосарій

Глосарій – це словник основних використовуваних термінів. Його можна розглядати як документ, який засвідчує спільне розуміння термінології проекту розробника та замовника.

Глосарій проекту представлений наведений у табл. 1.3.

Таблиця 1.3

Глосарій проекту

Термін	Опис терміну
1. Основні поняття та категорії предметної області та проекту
Вимога	Дія, що виражається у наполегливій, категоричній, прохання виконати що-небудь.
Проектування	Процес створення проекту, прототипу, прообразу передбачуваного або можливого об'єкта, стану.
Облік	Віддзеркалення господарської або іншої діяльності підприємства на підставі документів в різних вимірниках (кількісних і (або) якісних).
Рахунок	Виражений у числах результат яких-небудь підрахунків, обчислень; загальна кількість, підсумок.

Закінчення табл. 1.3

2. Користувачі системи
Замовник	Особа (фізична або юридична), зацікавлена ​​у виконанні виконавцем робіт, наданні їм послуг або придбання у продавця будь-якого продукту (в широкому сенсі).
Клієнт	Загальна назва суб'єкта, який використовує деякі послуги.
Менеджер по проектуванню	Фахівець, що професійно займається торгівельною діяльністю.
3. Вхідні та вихідні документи
Заявка	Документ, отриманий від клієнта. В ньому описано вимогу виготовити певну продукцію на основі укладеного договору.
Термін	Опис терміну
Звіт	Письмове повідомлення про виконання певної певної роботи
Стан договору	Поточні договірні обов’язки сторін.

3.2. Бачення проекту

Бачення проекту виявляє опис сутності проекту за допомогою визначення проблеми. Визначення проблеми наведено у таблиці 1.3.

Таблиця 1.4

Опис бізнес-проблеми

Визначення	Опис
Бізнес-проблема	На даний момент у відділі збуту переважає паперовий документообіг та ручні підрахунки.
Проблема зачіпає роботу	Відділу збуту
Наслідком проблеми є	Під час роботи з паперовими документами та виконанні ручних підрахунків допускається багато помилок та витрачається багато часу.
Успішне рішення проблеми досягається	Шляхом автоматизації бізнес-процесів документування договірних зобов’язань, ведення обліку збуту готової продукції на підприємстві, аналізу продажів.
Короткий опис ІТ-рішення і його результатів	Потрібно створити модуль ІС, який вирішить проблеми ведення обліку даних про клієнтів підприємства, ведення довідника продукції, документування договірних відношень з замовниками, формування відомостей аналізу продажів та обліку збуту готової продукції у розрізі контрагентів. Пересилка та передача інформації здійснюється практично миттєво. Швидкий доступ до інформації. Підвищується захист інформації в системі та безпека системи в цілому.

3.3. Розроблення варіантів використання

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

3.3.1. Діаграма варіантів використання.

Варіант використання - специфікація послідовностей дій (варіанти послідовностей і помилкові послідовності), які може здійснювати система, підсистема або клас, взаємодіючи з зовнішніми акторами.

Варіанти використання служать для документування функціональних вимог до програмних систем. Варіант використання описує деякий цілісний фрагмент поведінки системи, не вдаючись при цьому особливо внутрішньої структури суб'єкта. Визначення варіанту використання містить усі властиві йому види поведінки: основну послідовність, різні варіанти стандартної поведінки і різні виняткові ситуації із зазначенням відповідної реакції на них. З точки зору користувача деякі з видів поведінки виглядають як помилкові. Однак для системи помилкова ситуація є одним з варіантів поведінки, який повинен бути описаний і оброблений.

Варіант використання описує взаємодію програмної системи з акторами у вигляді послідовності повідомлень. У поняття актор входять люди, комп'ютерні системи і процеси.

При проектуванні програмної системи проводиться пошук таких класів для реалізації варіанту використання, які вдало поєднували б у собі необхідні ролі і не призводять до зайвого ускладнення системи. Реалізацію варіанту використання можна змоделювати у вигляді однієї або декількох кооперацій.

Для того, щоб більш точно зрозуміти як повинна працювати система, все частіше використовується опис функціональності системи через варіанти використання (Use Case або прецеденти). Варіанти використання це - опис послідовності дій, які може здійснювати система у відповідь на зовнішні впливи користувачів або інших програмних систем. Варіанти використання відображають функціональність системи з точки зору отримання значимого результату для користувача, тому вони точніше дозволяють ранжувати функції за значимістю одержуваного результату.

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

У процесі тестування, описані раніше варіанти використання дозволяють простіше оцінити точність реалізації вимог користувачів і дозволяють провести покрокову перевірку цих вимог.

Діаграма варіантів використання складається з акторів, для яких система проводить дію і власне дій, які описують те, що актор хоче отримати від системи (рис. 1.5). Актором у даному випадку є менеджер відділу збуту.

Рис. 1.5. Діаграма варіантів використання

3.3.2. Специфікація варіантів використання.

Специфікація варіантів використання створюється на основі варіантів використання системи, описуючи такі характеристики варіанту використання як діюча особа, передумова, постумова, тригер, сценарій. Наведено у подальших табл. 1.5. – 1.12.

Таблиця 1.5

Варіант використання «Редагування та перегляд довідників»

Контекст використання	Використовується для перегляду та редагування довідників.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження про створення розсилки.
Тригер	Отримання списку довідників.
Сценарій	Менеджер отримує розпорядження про перегляду та редагування довідників, запускає програмний додаток, і переглядає дану інформацію.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.6

Варіант використання «Формування звітів»

Контекст використання	Використовується при формуванні звітів менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження про формування звітів.
Тригер	Формування звітів.
Сценарій	Менеджер отримує розпорядження про створення нових звітів, запускає програмний продукт, і створює нові звіти.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.7

Варіант використання «Формування складу проекту»

Контекст використання	Використовується при формуванні складу проекту менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Контекст використання	Використовується при формуванні складу проекту менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження про формуванні складу проекту.
Тригер	Формуванні складу проекту.
Сценарій	Менеджер отримує розпорядження про створення складу проекту, запускає програмний продукт, і формує новий склад проекту.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.8

Варіант використання «Розрахунок вартості проекту»

Контекст використання	Використовується при розрахунку вартості проекту менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження розрахувати вартість проекту.
Тригер	Розрахунок вартості проекту.
Сценарій	Менеджер отримує розпорядження про розрахунок вартості проекту, запускає програмний продукт, і розраховує вартість даного проекту.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.9

Варіант використання «Ведення стану проекту»

Контекст використання	Використовується при веденні та перегляду стану проекту менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження переглянути стан проекту.
Тригер	Ведення та перегляд стану проекту.
Сценарій	Менеджер отримує розпорядження про перегляд стану проекту, запускає програмний продукт, и переглядає стан даного проекту.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.10

Варіант використання «Формування звіту про виконані проекти»

Контекст використання	Використовується при формування звіту про виконані проекти менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження сформувати звіт про виконані проекти.
Тригер	Формування звіту про виконані проекти.
Сценарій	Менеджер отримує розпорядження про формування звіту по виконаним проектам, запускає програмний продукт, и створює звіт.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.11

Варіант використання «Формування звіту про стадії проекту»

Контекст використання	Використовується при формування звіту про стадії проекту менеджером.
Діюча особа	Менеджер по роботі з клієнтами.
Передумова	Менеджер отримав розпорядження сформувати звіт про стадії виконання проекту.
Тригер	Формування звіту про стадії виконання проекту.
Сценарій	Менеджер отримує розпорядження про формування звіту по стадіям виконання проекту, запускає програмний продукт, и створює звіт.
Постумова	Менеджер аутентифікований в системі.

Таблиця 1.12

Варіант використання «Формування звіту про склад проекту»

Контекст використання	Використовується при формуванні звіту про склад проекту менеджером.
Діюча особа	Менеджер по роботі з клієнтами.

Закінчення табл. 1.12

Передумова	Менеджер отримав розпорядження сформувати звіт про склад проекту.
Тригер	Розрахунок вартості проекту.
Сценарій	Менеджер отримує розпорядження про сформуванні звіту про по складу проекту, запускає програмний продукт, і створює звіт.
Постумова	Менеджер аутентифікований в системі.