flag Судова влада України

Отримуйте інформацію лише з офіційних джерел

Єдиний Контакт-центр судової влади України 044 207-35-46

Повний текст "Технічного завдання на ЄСІС"

Погоджено Радою суддів: рішення №38 від 29.02.2008 р.
ЄСІС ТЗ 01–ЛУ

Технічне завдання (ТЗ) на Єдину судову інформаційну систему України (ЄСІС) встановлює загальні функціональні та інші вимоги до комплексу комп’ютерних програм, які повинні використовуватись в судах та інших установах системи судоустрою України.

Вимоги ТЗ є підставою для здійснення розробки модулів ЄСІС або вибору існуючих комп’ютерних програм, які відповідають вимогам до ЄСІС.

ТЗ визначає:

- функціональні та інші вимоги до ЄСІС в цілому;

- рамки ЄСІС (за що ЄСІС відповідає, за що – ні);

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

 



 

 

Анотація

Технічне завдання (ТЗ) на Єдину судову інформаційну систему України (ЄСІС) встановлює загальні функціональні та інші вимоги до комплексу комп’ютерних програм, які повинні використовуватись в судах та інших установах системи судоустрою України.

Вимоги ТЗ є підставою для здійснення розробки модулів ЄСІС або вибору існуючих комп’ютерних програм, які відповідають вимогам до ЄСІС.

ТЗ визначає:

- функціональні та інші вимоги до ЄСІС в цілому;

- рамки ЄСІС (за що ЄСІС відповідає, за що – ні);

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

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

Також окремим ТЗ повинні бути описані детальні вимоги до апаратного забезпечення ЄСІС та системи захисту інформації.

 

Зміст

Перелік умовних позначень та скорочень

1 Вступ

1.1 Назва системи
1.2 Підстави для розробки
1.3 Замовник
1.4 Головний підрядник

2 Призначення та цілі розробки
2.1 Призначення
2.2 Цілі
2.3 Завдання проекту
2.3.1 В цілому:
2.3.2 Для судів:
2.3.3 Для ДСА:
2.3.4 Для суддів:
2.3.5 Для адвокатів та сторін судового процесу:

3 Об’єкти автоматизації
3.1 Огляд цільової галузі
3.2 Перелік об’єктів автоматизації

4 Вимоги до системи
4.1 Вимоги до побудови системи
4.1.1 Обмеження на побудову системи
4.1.2 Принципи побудови
4.2 Вимоги до структури системи
4.2.1 Інформаційні рівні
4.2.2 Структура на рівні розгортання вузлів
4.2.3 Контури доступу до системи
4.3 Функціональні вимоги
4.3.1 Функціональні підсистеми
4.3.2 Підсистема «Судове діловодство та документообіг»
4.3.3 Підсистема «Судова статистика»
4.3.4 Підсистема «Розподіл судових справ»
4.3.5 Підсистема «Кадри»
4.3.6 Підсистема «Аналітика»
4.3.7 Підсистема «Законодавство та право»
4.3.8 Підсистема «Матеріально-технічне забезпечення»
4.3.9 Підсистема «Протоколювання та звукозапис судового процесу»
4.3.10 Відеоконференцзв’язок
4.3.11 Підсистема «Судова практика»
4.3.12 Державний реєстр судових рішень
4.3.13 Довідникова підсистема
4.3.14 Інформаційне забезпечення
4.3.15 Комплексна система захисту інформації (КСЗІ)
4.3.16 Інтернет-портал
4.3.17 Звернення громадян
4.3.18 Інформаційний кіоск
4.3.19 Підсистема «Фінансовий блок»
4.3.20 Адміністрування підсистем
4.3.21 Зв’язок та передача інформації
4.3.22 Забезпечення експлуатації та сервісного обслуговування
4.4 Вимоги до надійності

5 Вимоги до програмної документації

6 Стадії та етапи розробки
6.1 Принципи визначення черговості та пріоритетів
6.2 Стадії реалізації
6.2.1 Стадії реалізації системи в цілому
6.2.2 Етапи реалізації підсистем
6.3 Пріоритети та черговість
6.4 Строки реалізації

7 Порядок контролю та прийомки
 

 

Перелік умовних позначень та скорочень

Позначення

Опис

БД

База даних

ДСА

Державна судова адміністрація

ДСА України

ДСА України – центральна установа ДСА

ЕЦП

Електронний цифровий підпис (сертифікат)

ЄДРСР

Єдиний державний реєстр судових рішень

ЄСІС

Єдина судова інформаційна система

КСЗІ

Комплексна система захисту інформації

ЛБД

Локальна база даних

ПЗ

Програмне забезпечення

ТЗ

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

ТУ ДСА

Територіальне управління ДСА

ЦБД

Центральна база даних

 


 

 

1. Вступ

1.1 Назва системи

Назва системи: Єдина судова інформаційна система.

Скорочена назва: ЄСІС.

Розробник ЄСІС може дати їй умовну назву.

1.2 Підстави для розробки

Підставою для розробки є рішення Ради суддів України №8 від 09.02.2007р. «Про виконання Програми інформатизації судів загальної юрисдикції, інших органів та установ судової системи на 2004 – 2006 роки і щодо створення Єдиної судової інформаційної системи».

1.3 Замовник

Державна судова адміністрація України.

1.4 Головний підрядник

Головним підрядником є державне підприємство «Інформаційні судові системи» (ІСС), що підпорядковано ДСА України.

ІСС відповідає за розробку ЄСІС в цілому та координацію дій між її розробниками – субпідрядниками.

 

2. Призначення та цілі розробки

2.1 Призначення

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

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

2.2 Цілі

  1. Створення умов для забезпечення законності й обґрунтованості прийнятих судових рішень.
  2. Скорочення строків розгляду судових справ та скарг на основі використання інформаційних технологій.
  3. Підвищення ефективності процесів судового та загального діловодства, підготовки даних судової статистики в судах шляхом скорочення часу на обробку й передачу інформації.
  4. Підвищення достовірності та повноти інформації, що створюється, використовується та накопичується в процесі діяльності судових органів.
  5. Підвищення оперативності збору й оформлення судових матеріалів при підготовці й слуханні справ.
  6. Забезпечення оперативного доступу суддів і працівників апаратів судів до актуальної інформації із чинного законодавства та судової практики.
  7. Забезпечення об'єктивного аналізу судової практики і напрямків криміналізації суспільства на основі більших обсягів судової статистики й даних передісторії.
  8. Підвищення оперативності інформаційної взаємодії судів різних інстанцій, ДСА, Ради суддів України, органів виконавчої влади, прокуратури, сторін судового процесу.
  9. Підвищення ефективності інформаційних процесів кадрового, організаційного, матеріально-технічного й ресурсного забезпечення діяльності судів зі створенням інструмента інформаційно-аналітичної підтримки прийняття рішень у всіх сферах забезпечення судової діяльності.
  10. Підвищення інформованості суспільства про діяльність судів, забезпечення прозорості й відкритості стану системи правосуддя в Україні.

2.3 Завдання проекту

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

2.3.1 В цілому:

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

- Забезпечення єдиної бази даних та пошукової системи по судовим справам та документам, в тому числі – ведення ЄДРСР;

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

- Створення єдиної системи формування статистичної звітності;

- Впровадження єдиного порядку використання та ведення класифікаторів та довідників (ведення довідників "суди", "судді", "штатний розклад", "організації", "фізичні особи","сторони процесу"; ведення класифікаторів справ, типів документів, реквізитів документів, тощо);

- Використання електронного цифрового підпису (ЕЦП);

- Ведення БД судової практики та, можливо, судових прецедентів;

- Ведення БД зразків та шаблонів документів;

- Облік бланків суворої звітності та копій судових рішень, що створені з використанням бланків;

- Забезпечення впровадження відеоконференцзв’язкуміж судами різних інстанцій та слідчих ізоляторів.

2.3.2 Для судів:

- Автоматизація процесів діловодства суду, зменшення паперового діловодства, в тому числі:

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

- автоматизація процесів створення документів;

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

- процесуальний контроль;

- контроль виконання документів;

- Автоматизація більшості типових завдань прийняття рішень:

- Автоматизований розподіл судових справ;

- Автоматичне призначення часу судових засідань;

- Протоколювання та ведення звукозапису та, можливо, відеозапису судового процесу;

- Створення звітів про стан розгляду справ.

2.3.3 Для ДСА:

- Спрощення механізму створення звітів про стан розгляду справ;

- Автоматизація процесів діловодства ДСА

- автоматизація процесів створення документів;

- керування документообігом;

- контроль виконання документів;

- Ведення порталу судової влади;

- Керування кадрами.

2.3.4 Для суддів:

- Доступ до баз даних судових справ та ЄДРСР;

- Доступ до судової практики;

- Доступ до нормативно-правових та інших інформаційних баз даних.

2.3.5 Для адвокатів та сторін судового процесу:

- Доступ до інформації по справам з участю адвоката та сторін процесу;

- Своєчасне інформування про судові справи, що стосуються їх інтересів.

 

3. Об’єкти автоматизації

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

3.1 Огляд цільової галузі

До системи судоустрою належать:

- Судова система, яку складають суди загальної юрисдикції (Рисунок 3.1) та Конституційний Суд України;

- Державна судова адміністрація;

- Кваліфікаційні комісії суддів;

- Органи суддівського самоврядування (Рада суддів України, ради суддів областей та ін.);

- Академія суддів;

- Служба судових розпорядників.

Конституційний Суд України є єдиним органом конституційної юрисдикції і відокремленим від системи судів загальної юрисдикції, має свою систему судочинства, тому не розглядається в рамках ЄСІС.

Система судів загальної юрисдикції відповідно до Конституції України будується за принципами територіальності і спеціалізації.

Суди загальної юрисдикції:

за спеціалізацією:

- Загальні (в тому числі військові);

- Спеціалізовані (адміністративні та господарські);

територіально та за рівнем інстанції:

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

- апеляційні суди (перша та апеляційна інстанція), спеціалізовані апеляційні суди та Апеляційний суд України (апеляційна інстанція);

- вищі спеціалізовані суди – Вищий господарський та Вищий адміністративний суди (касаційна інстанція);

- Верховний Суд України (касаційна інстанція та розгляд справ з винятковими та виключними обставинами).

 

3.2 Перелік об’єктів автоматизації

Суди

 

*Верховний Суд України

1

Апеляційний суд України

1

Апеляційні суди (обласні, міст Києва та Севастополя, АРК,
військовий апеляційний суд Центрального регіону та військовий апеляційний суд
Військово-Морських Сил України)

29

Місцеві загальні суди (в тому числі військові)

679

*Вищий адміністративний суд України

1

Апеляційні адміністративні суди

7

Місцеві (окружні) адміністративні суди

27

*Господарські суди (місцеві, апеляційні та Вищий господарський суд України)

39

ДСА

 

ДСА України (центральний апарат)

1

ТУ ДСА в АР Крим, областях, містах Києві та Севастополі

27

Суб’єкти підтримки системи

 

Головний розробник

1

Центри підтримки ЄСІС (загальний та регіональні)

25

Учбові центри

1-2

Примітка – * Верховний, Вищий адміністративний та господарські суди мають власні автоматизовані системи. Впровадження ЄСІС для цих судів може бути передбачено в останню чергу.

 

 


 

 

Рисунок 3.1 – Судова система. Суди загальної юрисдикції


 

 

4. Вимоги до системи

4.1 Вимоги до побудови системи

4.1.1 Обмеження на побудову системи

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

- Велика кількість організацій (тільки судів більш 700);

- Організації розподілені на території Україні в усіх адміністративних центрах;

- Ієрархічна структура підпорядкування та/або інформаційної взаємодії ДСА України та ТУ ДСА; судів різних інстанцій;

- Велика кількість користувачів (більш 20 тис);

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

- Незадовільний стан засобів і каналів зв’язку;

- Необхідність централізації керування роботою системи (ведення ЄДРСР, класифікаторів та довідників і т.д.).

4.1.2 Принципи побудови

З врахуванням обмежень система повинна бути побудована на наступних принципах.

Централізація

Система повинна вирішувати завдання, пов’язані із забезпеченням доступу до всіх судових справ (ЄДРСР, БД з інформацією щодо судової практики, статистична звітність та ін.).

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

Стандартизація

Стандартизація та централізація ведення довідників та класифікаторів.

Організовується взаємодія з державними реєстрами з метою забезпечення достовірної ідентифікації фізичних та юридичних осіб – сторін судового процесу; ідентифікації прав власності та наявності обмежень щодо них.

Розподілення

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

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

Багаторівневість

На регіональних, та інших локальних рівнях можуть бути встановлені сервери, що дублюють функціональність серверу ЦБД для свого регіону (території) та виконують роль проміжних ланок між ЛБД та ЦБД.

Мінімальна достатність серверів

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

Віддалений доступ

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

Зовнішні користувачі мають обмежений доступ до ЦБД засобами мережі Інтернет.

Мінімізація числа операцій

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

4.2 Вимоги до структури системи

4.2.1 Інформаційні рівні

Система поділяється на три інформаційні рівні:

- Центральний;

- Середній;

- Користувача.

Центральний рівень – рівень, який забезпечує роботу центральної бази даних (ЦБД), ЄДРСР, Веб-порталу судової влади, сертифікаційного серверу та інших загальних інформаційних ресурсів системи.

Середній рівень – рівень організацій з великою кількістю користувачів та/або слабкими каналами зв’язку або місцева площадка для декількох організацій рівня користувача. На середньому рівні використовується локальна база даних (ЛБД), яка містить зріз даних ЦБД для цієї (цих) організації та проміжні дані. Між ЦБД та ЛБД проводиться автоматична синхронізація даних.

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

Рівень користувача – організації з надійними й швидкісними каналами зв’язку та окремі користувачі, що мають віддалений доступ до ЛБД або ЦБД

 

Рисунок 4.1 – Інформаційні рівні ЄСІС

4.2.2 Структура на рівні розгортання вузлів

При розгортанні системи організовуються наступні основні вузли:

Центральний рівень

- Центр підтримки ЄСІС;

- Веб-портал судової влади;

- Центр сертифікації;

Середній рівень

- Локальні центри;

Рівень користувача

- Організації та особи – користувачі;

- Зовнішні користувачі.

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

 

Рисунок 4.2 – Приклад організації рівнів та інформаційної взаємодії

4.2.3 Контури доступу до системи

Система повинна має три контури доступу:

- Загальний – доступ до загальнодоступної судової інформації, у тому числі зовнішнім користувачам;

- Відомчій – доступ тільки працівникам суду та ДСА до службової інформації, що не потребує спеціального захисту;

- Закритий – доступ строго визначеним особам до закритої інформації (містить державну та військову таємницю, тощо). Закритий контур не має фізичного зв’язку з відомчим рівнем та виконується згідно вимог КСЗІ.

4.3 Функціональні вимоги

4.3.1 Функціональні підсистеми

ЄСІС повинна включати наступні функціональні підсистеми.

Функціональні підсистеми, що забезпечують діяльність суду:

- Судове діловодство та документообіг;

- Судова статистика;

- Планування та розподіл судових справ;

- Кадри;

- Аналітика;

- Законодавство та право;

- Матеріально-технічне забезпечення;

- Протоколювання та звукозапис судового процесу;

- Відеоконференцзв’язок;

- Судова практика;

- Довідникова підсистема;

- Фінансовий блок.

Взаємодія з громадськістю:

- Інтернет-портал;

- Державний реєстр судових рішень;

- Звернення громадян;

- Інформаційний кіоск.

Забезпечуючи та технологічні:

- Адміністрування підсистем;

- Інформаційне забезпечення;

- Комплексна система захисту інформації;

- Зв’язок та передача інформації;

- Забезпечення експлуатації та сервісного обслуговування;

- Навчання кадрів.

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

4.3.2 Підсистема «Судове діловодство та документообіг»

4.3.2.1 Призначення

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

4.3.2.2 Вимоги до підсистеми

Підсистема повинна мати наступну функціональність:

- Реєстрацію та розподіл вхідної кореспонденції за виконавцями; відправку вихідної кореспонденції; реєстрацію внутрішніх документів; можливість зберігання графічної (відсканованої) копії зареєстрованого документа;

- Створення та зберігання процесуальних, організаційних, управлінських та інших документів судів і ДСА;

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

- Ведення інформації за судовими справами у повному обсязі (можливість ведення безпаперової судової справи в електронному вигляді);

- Реєстрацію процесуальних дій та документів у справі з автоматичною зміною стану справи, якщо це передбачено зареєстрованою дією та(або) документом;

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

- Постановка на контроль та здійснення контролю виконання вхідних та внутрішніх документів, автоматичне інформування виконавців посадових осіб, які здійснюють контроль, о проблемах пов’язаних зі строками виконання документів;

- Облік та контроль використання бланків суворої звітності при видачі (виготовленні) копій судових рішень;

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

- Використання електронного цифрового підпису (ЕЦП) для затвердження та узгодження документів, що отримують офіційний статус;

- Оперативний пошук справ та документів за реквізитами; індексація документів та контекстний пошук по текстах документів;

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

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

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

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

4.3.3 Підсистема «Судова статистика»

4.3.3.1 Призначення

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

4.3.3.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

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

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

- Генерацію звітів про стан здійснення правосуддя за правилами, передбаченими інструкціями з формування звітності;

- Передачу карток та звітів по інстанціях;

- Генерацію підсумкових звітів по раніш створеним проміжним звітам.

Необхідно передбачити можливість створення користувачем особистих форм (шаблонів) звітів для генерації внутрішніх звітів судів, палат судів, ДСА.

Підсистема ведення карток на рівні інформації повинна максимально бути інтегрована з підсистемою судового діловодства та документообігу. Інформація по справі (атрибути справи) в рамках системи діловодства та в обліково-статистичних картках повинна бути спільною, її не потрібно вводити в картку повторно, якщо вона була зареєстрована в атрибутах справи, та навпаки.

4.3.4 Підсистема «Розподіл судових справ»

4.3.4.1 Призначення

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

4.3.4.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Підсистему попередньої настройки. Підсистема настройки повинна забезпечувати:

- встановлення середнього терміну слухання справ різних категорій та/або їх коефіцієнту складності;

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

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

- Блок автоматичного розподілу судових справ. Блок повинен забезпечувати можливість використання декількох алгоритмів розподілу:

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

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

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

- Розподіл справ користувачем на випадок, якщо автоматичний розподіл не може бути застосовано;

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

Підсистема розподілу повинна бути інтегрована з підсистемою діловодства.

4.3.5 Підсистема «Кадри»

4.3.5.1 Призначення

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

4.3.5.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Централізоване ведення довіднику типових посад;

- Централізоване ведення довіднику організацій судової системи (інтеграція з підсистемою «Інформаційне забезпечення»);

- Створення та підтримку в актуальному стані штатного розкладу організації (суду, ТУ ДСА, ДСА). Штатний розклад включає:

- перелік та ієрархію (вкладеність) структурних підрозділів організації;

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

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

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

- Підтримка діловодства та документообігу кадрового забезпечення (інтеграція з підсистемою діловодства та документообігу).

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

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

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

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

4.3.6 Підсистема «Аналітика»

4.3.6.1 Призначення

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

4.3.6.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Доступ до блоку генерації звітів підсистеми судової статистики;

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

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

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

4.3.7 Підсистема «Законодавство та право»

4.3.7.1 Призначення

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

4.3.7.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

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

- Бистрий пошук по реквізитах нормативно-правових актів;

- Індексація документів та повнотекстовий контекстний пошук по текстах документів;

- Система типізованих закладок користувача (вибранні документи, портфель, папка), що забезпечує бистрий доступ до найбільш потрібних документів;

- Підсистема організації зв’язування нормативно-правових актів, їх розділів і статей з категоріями справ та типами документів;

Необхідно забезпечити можливість інтеграції підсистеми з підсистемою Підсистема «Судове діловодство та документообіг» таким чином, щоб по справам та документам було можливо оперативно переглянути зв’язані з їх категорію або типом нормативно-правові акти.

4.3.8 Підсистема «Матеріально-технічне забезпечення»

4.3.8.1 Призначення

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

4.3.8.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Ведення кодифікаторів та номенклатури матеріально-технічних засобів, що використовуються в судах;

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

- Облік матеріально-технічних та інших засобів (включаючи нематеріальні активи), що знаходяться в судах і ДСА. Ведення паспортів технічних засобів (характеристики, стан, проведені та заплановані обслуговування, тощо). Прив’язка одиниць обліку до будівель і приміщень, де вони знаходяться, та відповідальних осіб. Збереження історії руху (переміщень) засобів.

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

- Управляння заявками на поставку матеріальних засобів;

- Управління заявками на обслуговування та ремонт технічних засобів.

4.3.9 Підсистема «Протоколювання та звукозапис судового процесу»

4.3.9.1 Призначення

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

4.3.9.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Здійснення звукозапису з можливістю її зупинити на час перерви та подовжити;

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

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

- Захист протоколів завершених засідань з використанням ЕЦП;

- Створення копій протоколу зі звукозаписом на CD та інші носії інформації.

Система протоколювання повинна бути інтегрована з підсистемою діловодства та документообігу (створення нового протоколу не повинно вимагати повторного введення інформації стосовно справи).

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

4.3.10 Відеоконференцзв’язок

4.3.10.1 Призначення

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

4.3.10.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Забезпечення відеозв’язку між двома абонентами;

- Забезпечення відеозв’язку в режимі відео-конференції для декількох абонентів;

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

- Передачу електронних копій документів в режимі он-лайн.

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

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

4.3.11 Підсистема «Судова практика»

4.3.11.1 Призначення

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

4.3.11.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

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

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

- Забезпечення роботи блоку підтримки судових рішень підсистеми Підсистема «Судове діловодство та документообіг».

Система судової практики може передбачати два рівні – рівень судової практики суду та загальна судова практика.

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

4.3.12 Державний реєстр судових рішень

4.3.12.1 Призначення

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

4.3.12.2 Вимоги до підсистеми

Вимоги до Державного реєстру визначаються Порядком ведення Єдиного державного реєстру судових рішень (постанова Кабміну № 740 від 25.05.2006 р).

Передача судових рішень технічному адміністратору реєстру для подальшої публікації в Держреєстрі повинна проходити автоматично після легалізації судового рішення в підсистемі «Судове діловодство та документообіг».

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

4.3.13 Довідникова підсистема

4.3.13.1 Призначення

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

4.3.13.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

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

- Інтеграція з підсистемами «Законодавство і право», «Судова практика», «Судова статистика» та «Облік кадрів».

4.3.14 Інформаційне забезпечення

4.3.14.1 Призначення

Підсистема встановлюється у Адміністратора ЄСІС та призначена для забезпечення єдиних підходів ведення судової інформації та уніфікації інформації ті інформаційних потоків в судовій системі.

4.3.14.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Централізоване ведення та розповсюдження довідників, державних класифікаторів, тезаурусів, визначень та скорочень, довідників юридичних та, можливо, фізичних осіб (далі – довідники);

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

- Ведення історії змін довідників.

4.3.15 Комплексна система захисту інформації (КСЗІ)

4.3.15.1 Призначення

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

4.3.15.2 Вимоги до підсистеми

Система КСЗІ складається з апаратної та програмної частин.

Програмна частина повинна мати наступну функціональність:

- Розмежування доступу користувачів до інформації в відповідності до прийнятої політики доступу до інформації;

- Захист документів, аудіо-протоколів, інших матеріалів судового процесу електронним цифровим підписом;

- Антивірусний захист інформації;

- Захист мережі суду від DDOS та хакерських атак і несанкціонованого доступу.

Вимоги до апаратної частини та докладні вимоги до програмної частини КСЗІ повинні бути викладені в додатковому ТЗ на КСЗІ.

4.3.16 Інтернет-портал

4.3.16.1 Призначення

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

4.3.16.2 Вимоги до підсистеми

Інтернет-портал повинен мати наступну функціональність:

- Публікація новин та об’яв стосовно діяльності судової влади;

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

- Нормативно-правова база даних стосовно діяльності судів та судової системи (бажаним є узгодження актуальності документів з БД сайту Верховної Ради http://rada.gov.ua/);

- Інформування громадян стосовно порядку звертання до суду, подання позовних заяв скарг та інша корисна інформація;

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

- Доступ до судової практики (інформаційна взаємодія з підсистемою Підсистема «Судова практика»);

- Доступ до Державного реєстру судових рішень;

- Доступ до сайтів судів України.

Інтернет-портал повинен відповідати вимогам «Порядку оприлюднення у мережі Інтернет інформації про діяльність органів виконавчої влади» (затверджено постановою Кабінету Міністрів України від 4 січня 2002 р. № 3) з врахуванням особливостей діяльності судів та інших органів судової влади.

4.3.17 Звернення громадян

4.3.17.1 Призначення

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

4.3.17.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Реєстрація звернень громадян;

- Автоматичний розподіл звернень за виконавцями;

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

- Аналіз стану та результатів розгляду звернень (інтеграція з підсистемою «Аналітика»).

Підсистема повинна забезпечувати роботу згідно вимог закону України «Про звернення громадян».

Підсистема «Звернення громадян» повинна бути максимально інтегрована з підсистемою «Судове діловодство та документообіг».

4.3.18 Інформаційний кіоск

4.3.18.1 Призначення

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

4.3.18.2 Вимоги до підсистеми

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

4.3.19 Підсистема «Фінансовий блок»

4.3.19.1 Призначення

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

4.3.19.2 Вимоги до підсистеми

Система повинна надати доступ строго визначеним особам до інформації щодо фінансового забезпечення судів.

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

Необхідно передбачити систему обміну інформацією між бухгалтерським ПЗ та ЄСІС.

4.3.20 Адміністрування підсистем

4.3.20.1 Призначення

Підсистема встановлюється у Адміністратора ЄСІС, деякі блоки – в ТУ ДСА і судах та призначена для супроводу роботи ЄСІС, забезпечення її працездатності.

4.3.20.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

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

- Централізоване оновлення версій програмних модулів підсистем ЄСІС (інтеграція з підсистемою «Зв’язок та передача інформації»);

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

4.3.21 Зв’язок та передача інформації

4.3.21.1 Призначення

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

4.3.21.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

- Онлайновий доступ з робочих місць користувачів до підсистем ЄСІС, що виконані з використанням інтернет- та інтранет-технологій (Інтернет-портал, судова практика, законодавство, корисні веб-сайти, тощо);

- Забезпечення роботи електронної пошти з використанням шифрування та ЕЦП;

- Підсистема реплікації. Оперативна передача справ, судових рішень, що отримали офіційний статус, та їх реквізитів до ЦБД та ЛБД судів або ТУ ДСА, до яких надіслано справу;

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

4.3.22 Забезпечення експлуатації та сервісного обслуговування

4.3.22.1 Призначення

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

4.3.22.2 Вимоги до підсистеми

Система повинна мати наступну функціональність:

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

- Планування оновлення програмного забезпечення та модулів ЄСІС, своєчасне інформування адміністратора системи про робочі місця, де встановлено старі версії модулів ПЗ (інтеграція з підсистемою «Підсистема «Фінансовий блок»);

4.4 Вимоги до надійності

Архітектура ЄСІС повинна забезпечити безперебійну роботу підсистем, що працюють в судах та ДСА, протягом робочого часу; підсистеми, що забезпечують роботу ЄСІС та онлайнових (Веб-портал та ін.) в режимі: 24 години на добу, 7 днів на тиждень – з запланованими технічними перервами у межах регламентованих процедур, визначених Замовником.

- Підсистеми ЄСІС повинні бути стійкими до відмов та зникнення зв’язку;

- Повинен бути забезпечений захист від несанкціонованого доступу до даних відповідно до вимог Закону України "Про захист інформації в автоматизованих системах";

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

Стійкість ЄСІС до відмов повинна забезпечуватися комплексом технічно-методичних заходів, в тому числі за рахунок: резервування технічних і програмних засобів, застосування джерел безперебійного живлення, організації резервних компонентів системи; створення резервних копій баз даних.

Надійність ЄСІС повинна забезпечуватися за рахунок: застосування надійного системного програмного забезпечення та систем управління базами даних; використання високонадійних технічних засобів; тестування ЄСІС та проведення її дослідної експлуатації; кваліфікованої експлуатації й технічного обслуговування.

 

5 Вимоги до програмної документації

До кожної підсистеми можуть бути додані наступні експлуатаційні програмні документи:

- Специфікація (обов’язково) – склад підсистеми та її документації;

- Формуляр (бажано) – основні характеристики програми, комплектність, інформація про експлуатацію програми;

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

- Онлайнова допомога (бажано) – варіант керівництва користувача в електронному вигляді, що викликається із програми та залежить від поточного режиму роботи користувача;

- Керівництво адміністратора (при необхідності);

- Відомість носіїв інформації (при необхідності) – перелік носії інформації, що поставляються з підсистемою для забезпечення її встановлення та експлуатації.

Зміст та оформлення програмної документації повинні відповідати вимогам ГОСТ ЄСПД19.ххх.

Склад та уточнені вимоги до програмної документації підсистем визначаються в ТЗ на кожну підсистему.

 

6 Стадії та етапи розробки

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

6.1 Принципи визначення черговості та пріоритетів

Принципи планування проекту повинні бути спрямовані на зменшення ризиків, пов’язаних з великими програмними проектами.

При визначенні черговості та пріоритетів реалізації проекту повинні бути враховані наступні принципи:

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

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

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

- Паралельна розробка підсистем. Наскільки це можливо, реалізація підсистем повинна здійснюватись паралельно (повинні бути враховані можливості розробника(ів) та залежність між підсистемами);

- Під час розробки наступною версією ЄСІС або її підсистем здійснюється експлуатація та підтримка попередньої впровадженої версії;

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

6.2 Стадії реалізації

6.2.1 Стадії реалізації системи в цілому

В цілому система повинна бути реалізована за чотири основних стадій:

  1. Начальна стадія. Стадія включає організаційні заходи пов’язані з пошуком розробників та укладанням договорів, плануванням проекту та ін.
  2. Розробка ТЗ. Створення ТЗ на підсистеми. На цій стадії можуть бути розроблені ТЗ на підсистеми, що повинні бути реалізовані в першу чергу. ТЗ на підсистеми другої черги розробляються на стадії реалізації.
  3. Реалізація (техно-робочий проект). Здійснюється поетапна реалізація та впровадження в тестову експлуатацію ЄСІС та її підсистем.
  4. Впровадження. Система в цілому передається в промислову експлуатацію.

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

6.2.2 Етапи реалізації підсистем

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

  1. Визначення виконавця підсистеми. Розробником підсистеми може бути головний розробник або субпідрядник, якщо головний розробник не спеціалізується на розробці подібних підсистем. Вибір субпідрядника здійснюється головним розробником та узгоджується із Замовником.
  2. Розробка та узгодження ТЗ на підсистему. ТЗ виконується розробником підсистеми, узгоджується з головним розробником та затверджується Замовником.
  3. Розробка прототипу підсистеми (ескізний проект). Прототип підсистеми презентується розробником Замовнику та головному розробнику з метою раннього виявлення зауважень до напрямку дій виконавця;
  4. Перша пілотна версія підсистеми. Повинні бути реалізовані основні, найбільш критичні функції системи. Перша версія по узгодженню з головним розробником впроваджується для тестової експлуатації на робочих місцях користувачів.
  5. Наступні версії підсистеми. В кожній наступній версії реалізується декілька функцій підсистеми. Реалізація версії (ітерація) включає стадії:

    - Уточнення. Збір зауважень користувачів стосовно роботи попередньої версії підсистеми. Уточнення технічного завдання, списку вимог до підсистеми та їх узгодження із Замовником.

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

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

  6. Впровадження в промислову експлуатацію.Здійснюється в рамках впровадження в промислову експлуатацію системи в цілому.

6.3 Пріоритети та черговість

Пріоритетність реалізації підсистем визначається трьома ступенями: «1.Критично», «2.Важливо», «3.Необхідно». Пріоритет визначає важливість підсистеми для Замовника відносно інших підсистем.

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

Черговість реалізації визначає розробник та узгоджує з Замовником.

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

Таблиця 6.1Пріоритети реалізації підсистем ЄСІС

Підсистема

Пріоритет

Черговість*

Судове діловодство та документообіг

1. Критично

 

Судова статистика

1. Критично

 

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

1. Критично

 

Державний реєстр судових рішень

1. Критично

 

Адміністрування підсистем

1. Критично

 

Інформаційне забезпечення

1. Критично

 

Зв’язок та передача інформації

1. Критично

 

Планування та розподіл судових справ

1. Критично

 

Судова практика

2.Важливо

 

Звернення громадян

2.Важливо

 

Кадри

2.Важливо

 

Законодавство та право

2.Важливо

 

Відеоконференцзв’язок

2.Важливо

 

Довідникова підсистема

2.Важливо

 

Комплексна система захисту інформації

2.Важливо

 

Аналітика

3.Необхідно

 

Матеріально-технічне забезпечення

3.Необхідно

 

Інтернет-портал

3.Необхідно

 

Інформаційний кіоск

3.Необхідно

 

Забезпечення експлуатації та сервісного обслуговування

3.Необхідно

 

Навчання кадрів

3.Необхідно

 

 

Примітка: * – черговість визначається на другій стадії (розробка ТЗ на підсистеми) реалізації.

6.4 Строки реалізації

Датою початку робіт необхідно вважати дату затвердження цього ТЗ та договору на розробку ЄСІС між Замовником та головним розробником системи. В зв’язку з чим вказані строки реалізації в місяцях без уточнення конкретних дат.

Таблиця 6.2Строки реалізації

Стадії та етапи

Строк, міс.

Начальна стадія

1–3

Розробка ТЗ

2–6

Реалізація

24–30

Етап 1. Підсистеми першої черги

12

Етап 2. Підсистеми другої черги

6–9

Етап 3. Підсистеми третьої черги

6–9

Впровадження

6

Всього

33–45

 

7. Порядок контролю та прийомки

Контроль та прийомка ЄСІС здійснюється поетапно.

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

Розробник повинен передавати Замовнику версії підсистеми, що пройшли обов’язкове альфа-тестування у розробника, безпомилково запускаються та виконують обов’язкові функції, що були заплановані на поточну версію.

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

В залежності від складності підсистеми бета-тестування здійснюється від одного до двох місяців. Кожна виявлена помилка та невідповідність вимогам реєструється представниками Замовника на форумі взаємодії одразу після виявлення проблеми. Представники розробника протягом 1–2 днів реєструють в форумі відповідь з інформацією про прийняте рішення по усуненню недоліків.

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

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

Впровадження в промислову експлуатацію ЄСІС в цілому здійснюється після прийому її підсистем та комплексних прийомо-здаточних випробувань ЄСІС (перевірка окремих підсистем та взаємодії підсистем між собою).