ТЕХНІЧНЕ ЗАВДАННЯ на ПЕП «ЕЛЕКТРОННИЙ ПОЛІС»

підсистемА «Електронний поліс»

Технічне завдання

На    32      сторінках

Виконано  відповідно до договору № 7-1/25-06/2015 (12 / 2015)

Київ – 2015

 

1     Загальні положення

1.1     Повна назва розробки - «Розробка підсистеми «Електронний поліс».

1.2     Скорочена назва – «Електронний поліс».

1.3     Виконавцем робіт є ТОВ «Комп’ютерні Інформаційні Технології» (далі – Виконавець).

1.4     Замовником робіт є Моторне (транспортне) страхове бюро України (далі – Замовник).

1.5     Розробка виконується на основі договору № 7-1/25-06/2015 (12/2015) від 25.06.2015 р. «Розробка підсистеми «Електронний поліс» та додатковій угоді № 1 від 17.07.2015 р. (далі – Договір).

1.1     Планові строки розробки:

              Дата початку робіт – 17.07.2015 р.

              Дата закінчення робіт – __.11.2015 р.

1.6     Перелік нормативних документів, які мають бути враховані при розробці:

              Закон України про обов’язкове страхування цивільно-правової відповідальності власників наземних транспортних засобів.

              Концепція Проекту «Електронний поліс» для договорів обов’язкового страхування цивільно-правової відповідальності власників наземних транспортних засобів в Україні;

              Паспорт проекту у складі тендерної документації;

              Технічні вимоги щодо розробки підсистеми «Електронний поліс» у складі тендерної документації.

2     Мета та призначення розробки

2.1. Мета розробки підсистеми “Електронний поліс” – запровадження на базі сучасних інформаційних технологій зручного та доступного для Страхувальників, Страховиків та контролюючих органів державної влади рішення із укладання та перевірки дійсності договорів ОСЦПВВНТЗ а також:

              забезпечення оперативного та безумовного внесення повної та достовірної інформації про укладені договори обов’язкового страхування цивільно-правової відповідальності власників наземних транспортних засобів (далі ОСЦПВВНТЗ) та повсякденного  контролю  за наявністю діючого полісу ОСЦПВВНТЗ для будь-якого транспортного засобу, зареєстрованого в Україні;

              спрощення доступу споживачів до страховиків-членів МТСБУ для укладання договору ОСЦПВВНТЗ через Інтернет – доступ;

              протидія страховому шахрайству для отримання незаконного страхового відшкодування, в тому числі, через укладання договорів страхування «заднім числом»;

              унеможливлення виготовлення та використання підроблених (фальшивих) полісів;

              підвищення кількості укладених договорів страхування та ступеню забезпеченості обов’язковим страхуванням цивільно-правової відповідальності власників наземних транспортних засобів;

              підвищення довіри населення до ОСЦПВВНТЗ;

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

 

2.2. Очікувані результати:

              підвищення зручності та доступності укладання договору страхування;

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

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

              покращення контролю з боку ДАІ;

              підвищення актуальності та якості даних щодо договорів ОСЦПВВНТЗ.

 

2.3.    Ефект від впровадження підсистеми «Електронний поліс»:

Для Держави:

              перехід на якісно новий рівень контролю за організацією та здійсненням ОСЦПВВНТЗ;

              Унеможливлення корупційних дій при організації виготовлення паперових бланків полісів;

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

              наближення до повного охвату страхуванням цивільної відповідальності власників наземних транспортних засобів для забезпечення страхових виплат постраждалим в ДТП та попередження шахрайських дій, пов’язаних з цим видом страхування через ефективну інформаційну взаємодію МТСБУ, страховиків, органів ДАІ, прикордонного та митного контролю;

              підвищення якості облікових даних в інформаційних системах МТСБУ, органів ДАІ, прикордонного та митного контролю;

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

 

Для МТСБУ:

              контроль над діяльністю з укладання договорів ОСЦПВВНТЗ в online-режимі;

              оперативна, повна та достовірна інформація щодо укладених договорів страхування в ЦБД МТСБУ;

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

              можливість з боку МТСБУ негайно, «одним кліком», ввести заборону на  реалізацію полісів певним страховим посередником або страховиком-порушником та/або банкрутом.

 

Для Страховиків:

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

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

              зниження витрат через унеможливлення укладання «непрозвітованого» договору страхування, протидію шахрайству при укладанні  договорів страхування, в тому числі, з боку недобросовісних страхових посередників.

 

Для Страхувальників:

              забезпечення можливості придбати повноцінний поліс ОСЦПВВНТЗ із застосуванням інтернет-технологій, «не виходячи з дому»;

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

              можливість самостійно та раціонально обрати страховика, без «підказок» недобросовісних посередників;

              можливість у будь який час звернутись до ЦБД МТСБУ для перевірки страхового забезпечення власного авто, в тому числі, одразу після оформлення договору страхування.

3     Характеристика об’єкту автоматизації

Обов’язкове страхування цивільно-правової відповідальності власників наземних транспортних засобів (ОСЦПВВНТЗ) регламентується Законом України «Про обов’язкове страхування цивільно-правової відповідальності власників наземних транспортних засобів».

Право укладання договорів ОСЦПВВНТЗ мають страхові компанії (Страховики), які мають відповідну ліцензію від моторного транспортного страхового бюро України (МТСБУ).  Для укладання договорів залучаються агенти, яким право укладати договори надають відповідні Страховики.

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

Договір вступає в дію після здійснення оплати та з дати початку дії, яка зазначається в договорі. Строк дії договору обмежується датою зазначеною в договорі.

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

Перевірка наявності та чинності договорів ОСЦПВВНТЗ здійснюється шляхом формування спеціалізованих запитів до ЦБД МТСБУ з використанням веб-доступу або через веб-сервіси.

Права доступу до інформаційних ресурсів ЦБД МТСБУ визначаються набором «ролей» які призначаються конкретним користувачам. Набір прав для пересічних громадян, «неавторизованих» користувачів, надає можливість за допомогою веб-доступу до ЦБД МТСБУ отримати доступ до «публічних» пошукових запитів для перевірки наявності укладеного договору та перевірки його статусу за реквізитами транспортного засобу або серією та номером полісу.

«Електронний поліс» - це ідентифікований запис в спеціалізованій  інформаційній системі обліку електронних страхових полісів.

 

4     Вимоги до підсистеми «Електронний поліс»

4.1   Вимоги до архітектури системи та основних метрик швидкодії

(TREQ_1)     Декомпозиція сервісів

 

З метою забезпечення відмовостійкості та масштабованості системи має бути реалізована  декомпозиція функції системи на невеликі функціональні сервіси («мікросервіси»). Основний принцип: «одна функція» – «один сервіс». Це дає можливість майже необмеженого гнучкого масштабування системи за рахунок включення окремих сервісів паралельно на різних серверах, оновлення окремих сервісів без зупинки системи (спочатку оновлюється сервіс на одному сервері, на цей сервер переключаються клієнти, а потім оновлюється на інших). Також значно підвищується відмовостійкість, покращуються можливості локалізувати проблему та здійснити реконфігурацію системи без її зупинки.

 

(TREQ_2)     Логіювання

Кожен сервіс повинен здійснювати логіювання самого себе, і вже після цього інформація з логів повинна інтегруватися в єдиний лог на сервері моніторингу (може використовуватися як додатковий, так і один із основних серверів).

 

(TREQ_3)        Архітектура та схема підключень

З точки зору захисту інформації, забезпечення швидкодії та полегшення масштабування системи, сервіси розподіляються на 2 групи:

·                    «Read-only» сервіси, які здійснюють тільки читання інформації і працюють зі спеціальною базою даних;

·                    «Read-write» сервіси, які безпосередньо забезпечують процедуру укладання договорів та внесення змін до них.

Внаслідок різного типу навантаження є потреба у різній конфігурації серверів. Тому доцільно одразу рознести зазначені сервіси на різні площадки. Доступ до «Read-write» надаватиметься тільки страховикам, через VPN з посиленими заходами безпеки, рівень відмовостійкості у цих сервісів має бути найвищим.

 

Архітектура наведена на рис 1. «Топологія сервісів ЦБД МТСБУ після впровадження підсистеми Електроннийполіс».



(TREQ_4)        Loadbalancing

Слід враховувати, що на наступних етапах функціонування Підсистеми навантаження може значно зрости, наприклад, за рахунок впровадження автоматичного контролю наявності полісів відеокамерами на дорозі. Система має бути готова для впровадження технології Loadbalancing для окремих сервісів.

 

(TREQ_5)        Формати взаємодії

 

Для роботи сервісів мають використовуватися формати RestFUL (варіанти відповіді XML/JSON) та SOAP (формат відповіді XML), опис метаданих у форматі wsdl (XSD-схема).

Для підключення страхових компаній до «read-write» сервісів необхідно передбачити використання VPN з’єднання. Підключення страхових компаній може здійснюватися одразу з декількох точок.

(TREQ_6)        Показники швидкодії та відмовостійкості

 

(TREQ_6_1) Час відгуку системи: читання – не більше 1 сек, запис – не більше 1 сек.

(TREQ_6_2) Доступність сервісу: протягом року доступність не менше ніж 99,98%, безперервна недоступність не більше 4 годин. (для довідки на цей час доступність сервісу GreenCard-online складає 99,986% за рік і загальний час простою не перевищував одну годину).

(TREQ_6_3) Максимально допустимий час втрати даних: 5 хв.

(TREQ_6_4) Кількість одночасних запитів на запис: 300/хв.

(TREQ_6_5) Кількість одночасних звернень на перевірку: 300/хв.

(TREQ_6_6) Обсяг укладання полісів: до 10 000 тис. в годину.

(TREQ_6_7) Кількість одночасно працюючих  компаній без погіршення продуктивності: до 200 (під одночасно працюючими розуміється здійснення транзакцій в рамках однієї хвилини).

4.2  Вимоги до «Read-only» сервісів системи

 

(RO_InfoPage) Інформаційна сторінка доступу до сервісів

 

Інформаційна сторінка доступу до сервісів повинна містити:

(RO_InfoPage_1) Прямі посилання на основні та тестові веб-сервіси;

(RO_InfoPage_2) Опис веб-сервісів та приклади;

(RO_InfoPage_3) Доступ до документації;

(RO_InfoPage_4) Приклад схеми бізнес-процесу;

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

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

(RO_InfoPage_7) Стрічка повідомлень користувачам від МТСБУ (створення нових повідомлень у стрічці через окремий довідник системи з полями Дата повідомлення, тема повідомлення, зміст повідомлення).

4.2.1  (RO_GetHistory) Сервіс отримання інформації про історію страхових випадків для розрахунку коефіцієнту бонус-малус

(RO_GetHistory_1)     Набір методів сервісу отримання інформації про історію страхових випадків для розрахунку коефіцієнту бонус-малус

 

Передбачається використання чотирьох окремих методів пошуку:

 

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

·         За VIN транспортного засобу;

·         За парою параметрів Прізвище + Державний номер транспортного засобу;

·         За парою параметрів ЄДРПОУ + Державний номер транспортного засобу.

 

(RO_GetHistory_2)     Вхідні параметри сервісу отримання інформації про історію страхових випадків та правила їх перевірки

 

Параметр

Формат

1

Ідентифікаційний код фізичної особи

10 цифр, або 2 літери та 5 цифр (серія та номер паспорту для осіб, які не мають ідентифікаційного коду)

2

VIN

Літери та цифри, до 17 символів

3

Прізвище

Тільки літери, до 30 символів

4

ЄДРПОУ

8 цифр

5

Державний номер

Літери та цифри, до 10 символів

 

 

(RO_GetHistory_3)     Правила пошуку історії страхових випадків

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

Для VIN та державних номерів з метою більш повного пошуку здійснюється приведення усіх символів у великі літери латиниці, пробіли, символи / та \ ігноруються, однаково трактуються наступні пари символів – 0 та O , I та 1, S та 5, G та 6, З та 3.

Для прізвищ з метою більш повного пошуку здійснюється приведення за наступними правилами: вважаються однаковою літерою - і, и, ы, вважаються однаковою літерою – е, є, э, ё, не враховуються - ь, ъ та апостроф.

 

(RO_GetHistory_4)     Алгоритм розрахунку коефіцієнту бонус-малус

 

·         У знайденому переліку договорів знаходиться останній;

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

·         Визначається кількість страхових випадків за цим договором;

·         Розраховується коефіцієнт бонус-малус, виходячи з попереднього класу бонус-малус та кількості страхових випадків (згідно таблиці, зазначеній в ст. 8 Закону України про ОСЦПВВНТЗ).

 

 

(RO_GetHistory_5)     Вихідні дані сервісу отримання інформації про історію страхових випадків

 

Сервіс повертає:

·         розрахований коефіцієнт бонус-малус (число в діапазоні від 0.5 до 2.45),

·         інформацію про історію страхових випадків у форматі таблиці з полями: 

-          Страхова компанія;

-          Номер полісу (паперового або електронного);

-          Рік початку дії договору;

-          Строк дії;

-          Прізвище/найменування страхувальника;

-          Клас бонус-малус; 

-          Кількість страхових випадків;

-          Тип ТЗ;

-          Повне найменування ТЗ.

4.2.2  (RO_GetPhysical) Сервіс отримання інформації про фізичну особу

 

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

 

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

 

Параметр

Формат

1

Ідентифікаційний код фізичної особи

10 цифр, або 2 літери та 5 цифр (серія та номер паспорту для осіб, які не мають ідентифікаційного коду)

 

(RO_GetPhysical_2)   Правила пошуку інформації про фізичну особу

 

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

·         знаходитиметься останній за датою початку дії договору запис у ЦБД МТСБУ;

·         визначатиметься Прізвище, Ім’я та По-батькові страхувальника, вказані у цьому договорі.

(RO_GetPhysical_3)   Вихідні дані сервісу отримання інформації про фізичну особу

 

Сервіс повертає Прізвище, Ім’я та По-батькові страхувальника.

 

4.2.3  (RO_GetVehicle) Сервіс отримання інформації про транспортний засіб за його державним номером/VIN

(RO_GetStatus_1)        Набір методів сервісу отримання інформації про транспортний засіб

 

Передбачається використання двох окремих методів пошуку:

 

·         За VIN транспортного засобу;

·         За Державним номером транспортного засобу та (опціонально) Маркою транспортного засобу.

 

 

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

 

Параметр

Формат

1

VIN

Літери та цифри, до 17 символів

2

Державний номер

Літери та цифри, до 10 символів

3

Марка

Літери та пробіли, до 30 символів

 

Для VIN та державних номерів з метою більш повного пошуку здійснюється приведення усіх символів в великі літери латиниці, пробіли, символи / та \ ігноруються, однаково трактуються наступні пари символів – 0 та O , I та 1, S та 5, G та 6, З та 3.     

 

(RO_GetStatus_3)        Правила пошуку інформації про транспортний засіб за його VIN

·         знаходитиметься останній за датою початку дії договору запис у ЦБД МТСБУ із вказаним VIN;

·         визначатиметься Державний номер, Марка, Модель та Тип транспортного засобу, вказані у цьому договорі.

 

(RO_GetStatus_4)        Правила пошуку інформації про транспортний засіб за його державним номером

 

·         знаходитиметься останній за датою початку дії договору запис у ЦБД МТСБУ із вказаним державним номером.

 

(RO_GetStatus_5)        Правила пошуку інформації про транспортний засіб за його державним номером та маркою

 

·         знаходитиметься останній за датою початку дії договору запис у ЦБД МТСБУ із вказаними державним номером та маркою авто;

·         визначатиметься його VIN, модель та тип транспортного засобу.

 

(RO_GetStatus_6)        Вихідні дані сервісу отримання інформації про транспортний засіб

 

 

Параметр

Тип

1

VIN

строка

2

Державний номер

строка

3

Марка

строка

4

Модель

строка

5

Тип транспортного засобу

код згідно довідника, наприклад A1, A2…

 

У випадку, якщо знайдено декілька транспортних засобів за запитом по державному номеру, сервіс у відповідь надає повідомлення, що транспортний засіб визначено неоднозначно і надає перелік транспортних засобів із таким державним номером.

4.2.4  (RO_GetStatus) Сервіс визначення статусу полісу за його кодом (номером) або державним номером транспортного засобу

 

(RO_GetStatus_1)        Набір методів сервісу визначення статусу полісу

 

Передбачається використання трьох окремих методів пошуку:

 

·         За кодом електронного полісу;

·         За серією та номером паперового полісу;

·         За державним номером транспортного засобу.

 

(RO_GetStatus_2)        Вхідні параметри сервісу визначення статусу полісу

 

Параметр

Формат

1

Код електронного полісу

Літери та цифри, 6 символів

2

Серія паперового полісу

2 літери

3

Номер паперового полісу

До 7 цифр

4

Державний номер авто

Літери, до 30 символів

 

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

(RO_GetStatus_3)        Правила визначення статусу полісу

Статус полісу визначається на дату запиту (тобто на поточну дату).

Передбачені наступні статуси договору:

·         Активна заявка;

·         Емітований/діючий договір;

·         Анульована заявка;

·         Прострочена заявка;

·         Достроково припинений договір;

·         Договір, що закінчив свою дію (строково);

·         Відсутні дані.

 

(RO_GetStatus_7)        Вихідні дані сервісу визначення статусу полісу

Сервіс повертає дані у наступному форматі або повертає повідомлення, що інформації за вказаними даними не знайдено.

Параметр

Формат

1

Номер полісу

Код електронного полісу або серія та номер паперового полісу

2

Форма договору

Електронна / паперова

3

Статус договору

Один з переліку:

·         Активна заявка

·         Емітований/діючий договір

·         Анульована заявка

·         Прострочена заявка

·         Достроково припинений договір

·         Договір, що закінчив свою дію (строково)

4

Дата запиту

Поточна дата

Інформація про страховика

5

Назва страховика

 

6

Статус страховика

Діючий член МТСБУ / Не член МТСБУ з [дата]

7

Телефон

 

8

Факс

 

9

E-mail

 

10

Поштова адреса

 

11

Сайт

 

Інформація про транспортний засіб

12

Державний номер

 

13

VIN

 

14

Тип (код)

 

15

Тип (назва)

 

16

Повна назва транспортного засобу

Марка + модель

 

4.2.5  (SMS_GetStatus) SMS-cервіс визначення статусу полісу за його кодом (номером) або державним номером транспортного засобу

 

(SMS_GetStatus_1)    Формат запиту SMS-сервісу

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

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

(SMS_GetStatus_2)    Формат відповіді SMS-сервісу

Передбачається наступний формат відповіді при успішному результаті:

Nomer polisu <номер>, SK <назва страхової>, діюча на <поточна дата>, forma <elektronna / paperova>, avto <державний номер ТЗ>, typ <назва типу>

та відповідь при неуспішному результаті:

Nemaye diyuchogo dogovoru na potochnu datu

 

4.2.6  (RO_GetDicts) Сервіс отримання інформації про зміни довідників

 

(RO_GetDicts_1)           Набір методів сервісу отримання інформації довідників

 

Передбачається використання 6 окремих методів для отримання інформації про зміни довідників:

 

·         Отримання повного довідника марок авто;

·         Отримання повного довідника моделей авто;

·         Отримання повного довідника населених пунктів, що мають МРЕО;

·         Отримання змін у довіднику марок авто за період;

·         Отримання змін у довіднику моделей авто за період;

·         Отримання змін у довіднику населених пунктів за період.

 

(RO_GetDicts_2)           Вхідні параметри сервісу отримання інформації довідників

Методи отримання повного довідника не отримуватимуть параметрів. Для методів отримання змін у довіднику застосовуватиметься діапазон дат, за який отримуються зміни довідників.

(RO_GetDicts_3)           Вихідні дані сервісу отримання інформації довідників

 

Формат довідника марок:

 

Параметр

Правила заповнення

1

Ідентифікатор марки

число

2

Назва марки (укр)

строка

3

Назва марки (рос)

строка

4

Назва марки (англ)

строка

5

Статус операції

нова / змінена / видалена

6

Дата останньої операції

 

 

Формат довідника моделей:

 

Параметр

Тип

1

Ідентифікатор моделі

число

2

Ідентифікатор марки

число

3

Назва моделі (укр)

строка

4

Назва моделі (рос)

строка

5

Назва моделі (англ)

строка

6

Статус операції

нова / змінена / видалена

7

Дата останньої операції

 

 

Формат довідника населених пунктів:

 

Параметр

Тип

1

Ідентифікатор населеного пункту

число

2

Ідентифікатор зони реєстрації

число

3

Назва населеного пункту

строка

4

Статус операції

нова / змінена / видалена

5

Дата останньої операції

 

4.3  «Read-write» сервіси підсистеми

4.3.1  (RW_NewContract) Сервіс перевірки та створення заявки

(RW_ChangeContract_1)        Набір методів сервісу перевірки та створення заявки

Передбачається використання 2 окремих методів:

·         Перевірка даних заявки;

·         Створення заявки.

 

(RW_ChangeContract_2)       Вхідні параметри сервісу перевірки та створення заявки

 

Найменування показника

Обов’язковість

Тип

1.   

Ідентифікатор запису у системі страховика

Так

Унікальний ідентифікатор, що заповнюється зі сторони страховика для більш зручного співставлення запитів та відповідей

2.   

Дата початку дії полісу

Так

Дата

3.   

Строк дії

Так

Довідник «Строки дії договорів»

4.   

Клас бонус-малус

Так

Довідник «Класи Бонус-малус»

5.   

k1

Так

Плаваюча кома (5, 2)

6.   

k2

Так

Плаваюча кома (5, 2)

7.   

k3

Так

Плаваюча кома (5, 2)

8.   

k4

Так

Плаваюча кома (5, 2)

9.   

k5

Так

Плаваюча кома (5, 2)

10.          

k6

Так

Плаваюча кома (5, 0)

11.          

K7

Так

Плаваюча кома (5, 0)

12.          

Пільга

Так

Довідник «Пільги»

13.          

Знижки

Так

Довідник «Знижки»

14.          

Франшиза

Так

Гроші

15.          

Страхова премія

Так

Гроші

16.          

Статус резидента

Так

Довідник «Статуси резидентів»

17.          

Статус особи-страхувальника (Фіз/Юр)

Так

Довідник «Статуси особи»

18.          

Ідентифікаційний код страхувальника

Так

ЄДРПОУ/ІПН страхувальника / Серія та номер паспорту для фізичних осіб, що не мають ідентифікаційного коду

19.          

Прізвище/найменування страхувальника

Так

 

Строка (100)

20.          

Ім’я страхувальника

Умовно обов’язковий. Заповнюється, якщо страхувальник – фізична особа

Строка (100)

21.          

По-батькові страхувальника

Умовно обов’язковий. Заповнюється, якщо страхувальник – фізична особа

Строка (100)

22.          

Дата народження страхувальника

Умовно обов’язковий. Заповнюється, якщо страхувальник – фізична особа

Дата

23.          

Адреса страхувальника

Так

Дата

24.          

Населений пункт - місце реєстрації ТЗ

Так

Довідник «Населені пункти – місця реєстрації ТЗ»

25.          

Державний номер ТЗ

Так

Строка (10)

26.          

VIN ТЗ

Так

Строка (20)

27.          

Тип ТЗ

Так

Довідник «Типи ТЗ»

28.          

Марка ТЗ

Так

Довідник «Марки авто»

29.          

Модель ТЗ

Так

Довідник «Моделі ТЗ»

30.          

Призначення ТЗ

Так

Довідник «Призначення ТЗ»

31.          

Повна назва забезпеченого ТЗ

Так

Строка (100)

32.          

Обмеження стажу водія

Умовно обов’язковий. Заповнюється  тільки для фізичних осіб

Довідник «Обмеження стажу водія»

33.          

Ознака використання ТЗ протягом 1 календ. місяця

Так

Бітове поле  (True/False)

34.          

Ознака використання ТЗ протягом 2 календ. місяця

Так

Бітове поле  (True/False)

35.          

Ознака використання ТЗ протягом 3 календ. місяця

Так

Бітове поле  (True/False)

36.          

Ознака використання ТЗ протягом 4 календ. місяця

Так

Бітове поле  (True/False)

37.          

Ознака використання ТЗ протягом 5 календ. місяця

Так

Бітове поле  (True/False)

38.          

Ознака використання ТЗ протягом 6 календ. місяця

Так

Бітове поле  (True/False)

39.          

Ознака використання ТЗ протягом 7 календ. місяця

Так

Бітове поле  (True/False)

40.          

Ознака використання ТЗ протягом 8 календ. місяця

Так

 

Бітове поле  (True/False)

41.          

Ознака використання ТЗ протягом 9 календ. місяця

Так

Бітове поле  (True/False)

42.          

Ознака використання ТЗ протягом 10 календ. місяця

Так

Бітове поле  (True/False)

43.          

Ознака використання ТЗ протягом 11 календ. місяця

Так

Бітове поле  (True/False)

44.          

Ознака використання ТЗ протягом 12 календ. місяця

Так

Бітове поле  (True/False)

45.          

Блок ЕЦП

Так

Електронний цифровий підпис інформації договору

 

(RW_ChangeContract_3)        Перелік перевірок інформації заявки

Сервіс повинен здійснювати перевірку коректності даних за наступними правилами:

Код

Повідомлення про помилку

Опис алгоритму перевірки

1.     

Страхова компанія немає прав на укладання нових договорів страхування

Здійснюється перевірка у довіднику страхових компаній на те, що страховик, який створює новий договір, має відповідні права

2.     

Помилка при перевірці ЕЦП

Здійснюється перевірка ЕЦП за допомогою спеціальної бібліотеки. Разом з повідомленням про помилку надається уточнююча інформація від криптографічної бібліотеки

3.     

Замінений поліс не знайдений в реєстрі полісів

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

4.     

Дата початку дії повинна бути більша за дату укладання договору

Якщо дата початку дії договору менша або дорівнює даті укладання договору, то формується повідомлення про помилку

5.     

Дата початку дії повинна дорівнювати або бути менша за поточну дату + 364 дні

Якщо дата початку дії договору більша за поточну дату + 364 дні, то формується повідомлення про помилку

6.     

Дата закінчення дії договору повинна  бути більша за дату початку дії договору та бути менша за дату початку договору + 366 днів

Якщо закінчення дії договору знаходиться поза межами діапазону між датою початку дії договору та датою початку дії договору + 366 днів, то формується повідомлення про помилку

7.     

Для юридичної особи не може бути пільги

Якщо статус особи «Ю» і вказана деяка пільга, то формується повідомлення про помилку

8.     

Довжина повної назви ТЗ повинна бути більша за 3 символи

Якщо довжина повної назви авто 3 або менше символи, то формується повідомлення про помилку

9.     

Якщо статус особи «Ф», то ім’я страхувальника повинно бути заповненим

Якщо статус особи «Ф» й  ім’я страхувальника не заповнено, то формується повідомлення про помилку

10.  

Невірний формат VIN. В коді тільки цифри або букви. Обов’язкова наявність цифри.

Якщо у VIN є деякі символи крім цифр та букв, або VIN тільки з букв, або довжина строки VIN менше 5 символів, то формується повідомлення про помилку

11.  

Для юридичної особи ЄДРПОУ страхувальника має бути заповнений і має складатися з 8 цифр

Якщо Статус особи дорівнює «Ю» та ЄДРПОУ  страхувальника містить символи, які не є цифрами, або довжина ЄДРПОУ не дорівнює 8 символів, то формується повідомлення про помилку

12.  

Обмеження стажу водія заповнюється для фізичних осіб, для юридичних осіб не заповнюється

Якщо поле «Обмеження стажу водія» заповнено і «Статус особи» = «Юридична», або якщо це поле не заповнене і «Статус особи» = «Фізична»  то формується повідомлення про помилку

13.  

Розмір франшизи не може перевищувати 2 відсотки від «Ліміту за збитки майну»

Якщо розмір франшизи перевищує 2 відсотки від діючого ліміту по майну, то формується повідомлення про помилку

14.  

Для фізичної особи ідентифікаційний код повинен бути заповненим і мати коректний формат

 

Якщо статус особи «Фізична особа», то довжина ІПН має складати 10 цифр або бути у форматі 2 літери та 6 символів (що відповідає інформації про осіб, які не мають ідентифікаційного коду), інакше формується повідомлення про помилку

15.  

Невірний формат державного номеру ТЗ для резиденту

Здійснюється перевірка формату номера відповідно до набору припустимих шаблонів державних номерів. Якщо державний номер не відповідає жодному припустимому шаблону, то формується повідомлення про помилку

 

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

 

(RW_ChangeContract_4)       Алгоритм генерації коду електронного полісу

Код електронного полісу має складатися з 6 символів: латинських літер та цифр, згенерованих випадковим чином. При генерації повинно гарантуватися неповторення раніше згенерованих кодів.

Наприклад:

Z4PFR2

Набір літер та цифр для генерації не повинен включати наступні символи: 1,I,0,O,Q.

Всього застосовується 31 символ, можливо 887 503 681 унікальних комбінацій, чого вистачить на довгий термін.

(RW_NewContract_1)                Перевірка електронного цифрового підпису

Накладання електронного цифрового підпису здійснюється на стороні системи страховика за допомогою криптографічних засобів «ІІТ-Користувач».

Перевірка ЕЦП здійснюється найпершою, до проведення інших перевірок.

Для перевірки ЕЦП має використовуватися відкритий ключ страхової компанії. Для цього має використовуватися локальне сховище відкритих ключів на сервері. Локальне сховище повинно періодично (не рідше 1 разу на добу) оновлюватися, в автоматичному режимі синхронізуючись за протоколом OCSP з сервером АЦСК.

(RW_ChangeContract_5)               Формат вихідних даних сервісу перевірки та створення заявки

Сервіс повертає результати роботи у наступному форматі:

Параметр

Інформація

1

Результат роботи 

Успішно / не успішно

2

Ідентифікатор запису у системі страховика 

Ідентифікатор, що заповнюється зі сторони страховика для більш зручного співставлення запитів та відповідей 

2

Ідентифікатор запису у системі ЦБД МТСБУ

Ідентифікатор, що заповнюється зі сторони ЦБД МТСБУ у форматі GUID для службових цілей (дебаг та логіювання інформації)

Дані при успішному створення заявки/договору

3

Код електронного полісу

6 символів

4

Статус договору

Один з переліку:

·         Активна заявка

·         Емітований/діючий договір

Дані при неуспішному створенні заявки/договору

5

Помилки

Перелік помилок у вигляді таблиці у форматі вказаному нижче

 

Формат переліку помилок:

Параметр

Інформація

1

Код помилки

Число

2

Найменування помилки

Строка

3

Додаткова інформація щодо помилки

Текстова інформація, що деталізує (конкретизує) повідомлення щодо помилки. Наприклад, у випадку помилки щодо накладання ЕЦП, це може бути детальний опис помилки з боку криптографічної бібліотеки.

4.3.2  (RW_ChangeStatus) Сервіс зміни статусу договору страхування

 

(RW_ChangeStatus_1)               Набір методів сервісу зміни статусу договору страхування

 

Передбачається використання 3 окремих методів для внесення змін до договору страхування:

 

·                    Підтвердження укладання договору;

·                    Дострокове припинення дії договору;

·                    Анулювання заявки.

 

(RW_ChangeStatus_2)     Вхідні дані сервісу зміни статусу договору страхування

Єдиним вхідним параметром сервісу зміни статусу договору є Код електронного полісу.

(RW_ChangeStatus_3)    Алгоритм роботи методу підтвердження укладання договору

Метод підтвердження укладання договору змінює статус договору з «активна заявка» на «укладений».

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

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

Якщо запису з вказаним номером не знайдено, то формується повідомлення «Запису з вказаним номером не знайдено».

Якщо запису з вказаним номером не має статусу заявки, то формується повідомлення «Запис з вказаним номером не має статусу активної заявки, а має статус:» + <назва статусу>.

(RW_ChangeStatus_4)    Алгоритм роботи методу дострокового припинення дії договору

 

Метод дострокового припинення дії договору змінює статус договору з «укладений» на «достроково припинений».

Дата дострокового припинення дії встановлюється наступною після дати здійснення операції.

Якщо запису з вказаним номером не знайдено, то формується повідомлення «Запису з вказаним номером не знайдено».

Якщо запис з вказаним номером не має статусу «укладений договір», або якщо поточна дата лежить за межами діапазону між датою початку (включно) та датою закінчення дії договору (не включно), то формується повідомлення «Запис з вказаним номером не є діючим договором».

 

(RW_ChangeStatus_5)    Алгоритм роботи методу анулювання заявки

 

Метод анулювання заявки переводить запис зі статусу «активна заявка» на «видалена заявка».

Якщо запису з вказаним номером не знайдено, то формується повідомлення «Запису з вказаним номером не знайдено».

Якщо запис з вказаним номером не має ні статусу «активна заявка», ні статусу «укладений договір», за умови що дата початку дії договору ще не настала, то формується повідомлення «Запис з вказаним номером не є активною заявкою».

 

(RW_ChangeStatus_6)    Вихідні дані сервісу зміни статусу договору

Сервіс повертає результати роботи у наступному форматі:

Параметр

Інформація

1

Результат роботи 

Успішно / не успішно

2

Код електронного полісу

6 символів

Дані при успішному результаті роботи

3

Статус договору

Статус договору після здійснення операції

4

Дата початку дії договору

Повертається тільки для методу підтвердження укладання договору

5

Дата закінчення дії договору

Повертається тільки для методу підтвердження укладання договору

6

Дата дострокового припинення дії договору

Повертається тільки для методу дострокового припинення дії договору

Дані при неуспішному результаті роботи

7

Помилки

Перелік помилок у вигляді таблиці у форматі вказаному нижче

 

Формат переліку помилок:

Параметр

Інформація

1

Код помилки

Число

2

Найменування помилки

Строка

3

Додаткова інформація щодо помилки

Текстова інформація, що деталізує (конкретизує) повідомлення щодо помилки. Наприклад, відображений поточний статус договору

4.3.3  (RW_GetChanges) Сервіс отримання інформації з історії операцій за договором страхування

(RW_ GetChanges _1)              Вхідні дані сервісу отримання інформації з історії операцій за договором страхування

 

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

Якщо запис з вказаним кодом не знайдений у базі даних формується відповідне діагностичне повідомлення.

 

(RW_ GetChanges _2)              Вихідні дані сервісу отримання інформації з історії операцій за договором страхування

Повертається реєстр змін у форматі таблиці

 

Поле

Інфомація

1

Тип операції

Створення заявки/підтвердження початку дії / анулювання заявки / дострокове припинення дії

2

Дата операції

Фактична дата здійснення операції

 

4.4  Служби рівня серверів баз даних

4.4.1  (DB_SyncEP_CDB) Служба передачі інформації про укладені договори з підсистеми «Електронний поліс» до ЦБД МТСБУ

 

Для здійснення централізованої аналітики та коректного і повноцінного функціонування усіх підсистем ЦБД МТСБУ інформація про усі договори укладені через підсистему «Електронний поліс» повинні потрапляти до основної бази даних системи. Періодичність синхронізації 1 доба.

Синхронізуються дані по договорах страхування. Для забезпечення швидкодії спочатку синхронізуються дані “як є”, а потім здійснюється перетворення даних у формат таблиць договорів ЦБД.

4.4.2   (DB_SyncCDB_EP) Служба передачі інформації про укладені договори з ЦБД МТСБУ до підсистеми «Електронний поліс»

Для повноцінного забезпечення роботи Read-only сервісів (таких наприклад як визначення статусу полісу) необхідно на рівні бази даних «read-only» здійснювати інтеграцію даних про договори укладені у вигляді паперового договору (які вносяться в ЦБД МТСБУ) та про договори укладені через підсистему «електронний поліс».

Копіювання даних з системи ЦБД МТСБУ має здійснюватися тільки у базу даних Read-only (у базу “read-write” копіювання не здійснюється) з періодичністю 1 доба.

 

4.4.3  (DB_Sync_Dict) Служба синхронізації змін даних довідників з основної бази даних ЦБД МТСБУ до ПЕП ЦБД МТСБУ

Оскільки інформація довідників ведеться спеціалістами МТСБУ на стороні основної бази даних системи, то синхронізація змін довідників має здійснюватися відповідною окремою серверною службою регулярно та автоматично (перевірка на наявність змін – 1 раз на добу). Синхронізуються довідники марок, моделей та населених пунктів – місць реєстрації.

4.4.4  (AdmCenter) Адміністративний центр

Функціями адміністративного центру є:

·         Реєстрація/відключення інформаційних систем страхових компаній;

·         Редагування системних довідників;

·         Налаштування системи;

·         Аудит подій, включаючи дії адміністраторів системи;

·         Керування правами доступу;

·         Налаштування бізнес-правил контролю даних.

Для адміністративного центру використовуватиметься існуючий адміністративний модуль ЦБД МТСБУ. 


 

4.5  (Security) Організація захисту інформації

 

(Security_1)  Для авторизації страхових компаній для укладання договорів в підсистемі Електронний поліс ЦБД МТСБУ здійснюється підключення страховика через VPN.

(Security_2)  Для авторизації страхових компаній безпосередньо в системі використовуватимуться логін.

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

(Security_4)            Неперервний моніторинг доступності сервісів та основних показників швидкодії системи мають здійснюватися засобами агентів PRTG.

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

(Security_6)            Для забезпечення цілісності використовуватиметься технологія ЕЦП описана вище.

(Security_7)            Усі події системи щодо підключення, запитів що надійшли, модифікацій даних, дії внутрішніх процесів та служб повинні протоколюватися.


 

4.6  (Chng_mgmt) Методологія управління змінами

Для організації управління змінами базовою виступатиме система контролю версій – Subversion (SVN).

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

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

Пропонується використати існуючу інфраструктуру в якій один екземпляр SVN з вихідними кодами знаходиться у розробника (SVN_DEV) , а інший – у замовника (SVN_MTIBU).

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

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

Також на основі описів змін автоматично формується перелік змін у вигляді текстового файлу який прив’язується до версії і стає доступним у програмному продукті через пряме посилання.

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

Усі зміни у програмному забезпеченні, що переносяться на основну платформу, мають бути задокументовані у реєстрі змін. Реєстр змін ведеться у довіднику Системи. В реєстрі змін вказується версія оновленого ПЗ, дата оновлення, текстова інформація, що описує оновлення Системи з функціональної точки зору («людською» мовою). Користувачі отримують інформацію щодо змін у Системі в головному вікні програми у вигляді повідомлення. До релізу автоматично додається згаданий текстовий файл з коментарями розробників щодо змін та посиланнями на зауваження/доопрацювання на трекері.

До структури посилання у веб-сервісі обов’язково додається номер версії. Одночасно можуть бути доступні декілька версій одного сервісу, причому при випуску версій має забезпечуватися пряма і обернена сумісність (forwardandbackwardcompatibility).

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

 


 

4.7  (Support) Методологія підтримки (основні положення)

Ключовими питаннями для забезпечення технічної підтримки системи є питання здійснення регулярних процедур обслуговування серверів та баз даних (Maintenance) засобами SQL Server ManagementStudio та процедури моніторингу доступності ресурсів (scheduledmonitoring) з використанням PRTG.

Щодо підтримки користувачів, інформація від користувачів та адміністраторів надходить наступними шляхами:

·         автоматично сформовані та відправлені програмним забезпеченням повідомлення про помилки, усі повідомлення від усіх сервісів записуються у логи серверу Windows або в логиSQlServerу і у разі виявлення критичних помилок здійснюється відправка цієї інформації поштою та смс до чергових адміністраторів;

·         телефони гарячої лінії;

·         чат підтримки.

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

1.  Перелік дій користувача, що призводить допомилки;

2.  Додаткова інформація про помилку (скріншоти, копія інформації про помилку InWare тощо).

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

 

 

 

5     Склад та зміст робіт із виконання даного ТЗ

5.1     Склад і зміст робіт наведено в Таблиця 5.1.

Таблиця 5.1 Склад і зміст робіт по розробці підсистеми «Електронний поліс».

Перелік робіт за Договором

Строк виконання, календарних днів

1

Розробка технічного завдання

15

2

Розробка специфікації веб сервісів

100

3

Налаштування готових компонент підсистеми, розробка нових модулів підсистеми

4

Внутрішнє тестування  підсистеми

5

Розробка технічної документації

6

Розгортання та налаштування тестової платформи у замовника

7

Випробування підсистеми

8

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

9

Розгортання та налаштування промислової платформи у замовника

5

 

6     Порядок здачі-приймання робіт

6.1     Проведення робіт з випробувань та приймання підсистеми «Електронний поліс»» повинно проводитись згідно з цим Технічним завданням.

6.2     Порядок здачі-приймання робіт передбачає:

              Проведення випробувань на тестовій платформі у Замовника;

              Внесення виправлень до підсистеми та технічної документації за результатами випробувань;

              Розгортання та налаштування ПЗ на промисловій платформі Замовника;

              Передачу вихідних програмних кодів;

              Передачу проектної та експлуатаційної документації.

 

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

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

              Опис підсистеми «Електронний поліс»;

              Опис сервісів підсистеми «Електронний поліс»;

              Керівництво адміністратора підсистеми «Електронний поліс».

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

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

 

7     Вимоги до складу документації на розробку

Перелік експлуатаційної документації, яка розробляється Виконавцем:

              Опис підсистеми «Електронний поліс»;

              Опис сервісів підсистеми «Електронний поліс»;

              Керівництво адміністратора підсистеми «Електронний поліс».

 

Comments